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本 章 介 绍 了 Linux 内 核 引 导 过 程 。 此 处 你 将 在 这 看 到 一 些 描述 内 核 加 载 过 程 的 整个 周期 的 文 


e 从 引导 程序 到 内 核 - 介绍 了 从 启动 计算 机 到 内 核 执行 第 一 条 指令 之 前 的 所 有 阶段 ; 

e 在 内 核 设 置 代码 的 第 一 步 - 介绍 了 在 内 核 设 置 代码 的 第 一 个 步骤 。 你 会 看 到 堆 的 初始 化 ， 
查询 不 同 的 参数 ， 如 EDD? IST 等 ... 

© 视频 模式 初始 化 和 保护 模式 切换 - 介绍 了 内 核 设 置 代码 中 的 视频 模式 初始 化 ， 并 切换 到 保 
护 模式 。 

o 切换 64 位 模式 - 介绍 切换 到 64 位 模式 的 准备 工作 以 及 切换 的 细节 。 

© 内 核 解 压缩 - 介绍 了 内 核 解压 缩 之 前 的 准备 工作 以 及 直接 解压 缩 的 细节 。 

e 内 核 地 址 随机 化 - 介绍 了 Linux 内 核 加 载 地 址 随机 化 的 细节 。 


内 核 引 导 过 程 . 第 一 部 分 . 


从 引导 加 载 程序 内 核 


如 果 看 过 我 在 这 之 前 的 文章 ， 你 就 会 知道 我 已 经 开始 涉足 底层 的 代码 编写 。 我 写 了 一 些 关于 
Linux x86_64 汇编 的 文章 。 同 时 ， 我 开始 深入 研究 Linux 源 代码 。 底 层 是 如 何 工 作 的 ， 程 序 
是 如 何在 电脑 上 运行 的 ， 它 们 是 如 何在 内 存 中 定位 的 ， 内 核 是 如 何 管理 进程 和 内 存 ， 网 络 堆 
栈 是 如 何在 底层 工作 的 等 等 ， 这 些 我 都 非常 感 兴 趣 。 因 此 ， 我 决定 去 写 另 外 的 一 系列 文章 关 
于 x86_64 框架 的 Linux Aik o 


注意 这 不 是 官方 文档 ， 只 是 学 习 和 分 享 知识 
需要 的 基础 知识 


。 理解 C 代码 
。 理解 汇编 语言 代码 (AT&T 语法 ) 


不 管 怎样 ， 如 果 你 才 开始 学 一 些 ， 我 会 在 这 些 文章 中 尝试 去 解释 一 些 部 分 。 好 了 ， 人 小 的 介绍 
结束 ， 我 们 开始 深入 内 核 和 底层 。 


我 们 的 文章 是 基于 Linux 内 核 3.18 版 本 进行 的 ， 如 果 后 续 的 内 核 版 本 有 任何 改变 ， 我 将 作出 
相应 的 更 新 。 


神奇 的 电源 按钮 ， 接 下 来 会 发 生 什 么 ? 


尽管 这 是 一 系列 关于 Linux 内 核 的 文章 ， 我 们 在 第 一 章 并 不 会 从 内 核 代码 开始 。 电 脑 在 你 按 
人 ， 就 开始 工作 。 主 板 发 送信 号 给 电源 ， 而 电源 收 到 信号 后 会 给 电脑 供应 合 

适 的 电量 。 一 旦 主板 收 到 了 电源 备 受 信号 ， 它 会 尝试 启动 CPU 。CPU 则 复位 寄存 器 的 所 有 
数据 ， 并 设置 每 个 寄存 器 的 预定 值 。 


80386 以 及 后 来 的 CPUs 在 电脑 复位 后 ， 在 CPU 寄存 器 中 定义 了 如 下 预定 义 数据 : 


IP Oxf FFO 
CS selector Oxf000 
CS base Oxffff0000 


处 理 器 开始 在 实 模式 工作 。 我 们 需要 退回 一 点 去 理解 在 这 种 模式 下 的 内 存 分 段 机 制 。 从 8086 
到 现在 的 Intel 64 位 CPU > MA x86 兼 容 处 理 器 都 支持 实 模 式 。8086 处 理 器 有 一 个 20 位 寻 址 
这 意味 着 它 可 以 对 0 到 2420 位 地 址 空间 ( 1MB ) 进行 操作 。 不 过 它 只 有 16 位 的 寄存 
器 ， 所 以 最 大 寻 址 空间 是 2^16 即 0xffff (64 KB) 。 实 模式 使 用 段 式 内 存 管 理 来 管理 整个 内 


存 空 间 。 所 有 内 存 被 分 成 国定 的 65536 字 节 (64 KB) 大 小 的 小 块 。 由 于 我 们 不 能 用 16 位 寄存 
器 寻 址 大 于 64KB 的 内 存 ， 一 种 替代 的 方法 被 设计 出 来 了 。 一 个 地 址 包括 两 个 部 分 : 数据 段 
起 始 地 址 和 从 该 数据 段 起 的 偏 移 量 。 为 了 得 到 内 存 中 的 物理 地 址 ， 我 们 要 让 数据 段 乘 16 并 加 
上 偏 移 量 : 


PhysicalAddress = Segment * 16 + Offset 


举 个 例子 ， 如 果 cs:IP 是 0x2000:0x0010 ， 则 对 应 的 物理 地 址 将 会 是 


>>> hex((@x2000 << 4) + 0x0010) 
'@x20010' 


不 过 如 果 我 们 使 用 16 位 2 进 制 能 表示 的 最 大 值 进 行 寻 址 : exffff:0xffff ， 根 据 上 面 的 公式 ， 
结果 将 会 是 : 


>>> hex((Oxffff << 4) + 0xffff) 
'ox10ffef' 


这 超出 1MB 65519 字 节 。 既 然 实 模式 下 ，CPU 只 能 访问 1MB 地 址 空间 ， oxioffet ERA 
A20 缺陷 的 oxooffef ° 


我 们 了 解 了 实 模式 和 在 实 模式 下 的 内 存 寻 址 方式 ， 让 我 们 来 回头 继续 来 看 复位 后 的 寄存 器 
值 。 


cs 寄存 器 包含 两 个 部 分 : 可 视 段 选择 器 和 隐 含 基 址 。 结合 之 前 定义 的 cs 基 址 和 rp 
值 ， 逻辑 地 址 应 该 是 : 


Oxf fFFOOOO : OxFFFO 


这 种 形式 的 起 始 地 址 为 EIP 寄 存 器 里 的 值 加 上 基 址 地 址 : 


>>> Oxffff0000 + Oxfff0 
[Oxi hie 


得 到 的 exfffffff@ 是 4GB - 16 字 节 。 这 个 地 方 是 复位 向 量 (Reset vector) ° 这 是 CPU 在 
重 置 后 期 望 执行 的 第 一 条 指令 的 内 存 地 址 。 它 包含 一 个 jump 指令 ， 这 个 指令 通常 指向 BIOS 
入 口 点 。 举 个 例子 ， 如 果 访 问 coreboot 源 代码 ， erry : 


.section ".reset", "ax", %progbits 
.code16 
.globl _start 
_start: 
.byte Oxe9 
.int _starti6bit - ( .+2) 


上 面 的 跳 转 指 令 ( opcode - 0xe9) 跳 转 到 地 址 _starti6bit - ( . + 2) 去 执行 代码 。 
reset Æ 16 字 节 代码 段 ， 起 始 于 地 址 gxfffffffg ( src/cpu/x86/16bit/reset16.1d ) ， 
此 CPU 复位 之 后 ， 就 会 跳 到 这 个 地 址 来 执行 相应 的 代码 : 


SECTIONS { 
/* Trigger an error if I have an unuseable start address */ 
_bogus = ASSERT(_starti6bit >= Oxffff0000, "_starti6bit too low. Please report.") 


_ROMTOP = OxfffffffO; 

. = _ROMTOP; 

„reset. : {f 
*(.reset); 
. = 15; 
BYTE(0x00); 


现在 BIOS 已 经 开始 工作 了 。 在 初始 化 和 检查 硬件 之 后 ， 需 要 寻找 到 一 个 可 引导 设备 。 可 引导 
设备 列表 存储 在 在 BIOS 配置 中 , BIOS 将 根据 其 中 配置 的 顺序 ， 尝 试 从 不 同 的 设备 上 寻找 引 
导 程 序 。 对 于 硬盘 ，BIOS 将 尝试 寻找 引导 局 区 。 如 果 在 硬盘 上 存在 一 个 MBR 分 区 ， 那 么 引导 
扇 区 储存 在 第 一 个 扁 区 (512 字 节 ) 的 头 446 字 节 ， 引 导 扇 区 的 最 后 必须 是 gx55 和 oxaa ， 这 
2 个 字 节 称 为 魔术 字 节 (Magic Bytes)， 如 果 BIOS 看 到 这 2 个 字 节 ， 就 知道 这 个 设备 是 一 个 可 
引导 设备 。 举 个 例子 : 


; Note: this example is written in Intel Assembly syntax 
[BITS 16] 
[ORG 0x7c00] 


boot: 
mov al, '!' 
mov ah, 0x0e 
mov bh, 0x00 
mov bl, 0x07 


int 0x10 
jmp $ 


times 510-($-$$) db 0 


db 0x55 
db Oxaa 


构建 并 运行 : 
nasm -f bin boot.nasm && qemu-system-x86_64 boot 
这 让 QEMU 使 用 刚才 新 建 的 boot 二 进 制 文件 作为 磁盘 镜像 。 由 于 这 个 二 进 制 文件 是 由 上 述 


汇编 语言 产生 ， 它 满足 引导 扇 区 (起 始 设 为 ox7co0 , 用 Magic Bytes 结 束 ) 的 需求 。QEMU 将 这 
个 二 进 制 文件 作为 磁盘 镜像 的 主 引 导 记 录 (MBR)。 


将 看 到 : 


SeaBIOS (version 1.7.5-20140531_171129-lamiak) 


iPXE Chttp://ipxe.org) 00:03.0 C980 PCIZ.10 PnP PMM+07F90BA0+07EFOBAO C980 


Booting from Hard Disk... 





在 这 个 例子 中 ， 这 上 段 代码 被 执行 在 16 位 的 实 模式 ， 起 始 于 内 存 0X7c00。 之 后 调用 0x10 中 断 
打印 ! 符号 。 用 0 填充 剩余 的 510 字 节 并 用 两 个 Magic Bytes exaa 和 oxs5 结 


可 以 使 用 objdump 工具 来 查看 转 储 信息 : 


nasm -f bin boot.nasm 
objdump -D -b binary -mi386 -Maddr1i6,datai6,intel boot 


一 个 丨 实 的 启动 扇 区 包含 了 分 区 表 ， 以 及 用 来 启动 系统 的 指令 ， 而 不 是 像 我 们 上 面 的 程序 ， 
只 是 输出 了 一 个 感叹 号 就 结束 了 。 从 启动 户 区 的 代码 被 执行 开始 ，BIOS 就 将 系统 的 控制 权 转 
移 给 了 引导 程序 ， 让 我 们 继续 往 下 看 看 引导 程序 都 做 了 些 什么 


NOTE: 强调 一 点 ， 上 面 的 引导 程序 是 运行 在 实 模式 下 的 ， 因 此 CPU 是 使 用 下 面 的 公式 进 
物理 地 址 的 计算 的 : 


PhysicalAddress = Segment * 16 + Offset 


而 且 正 如 我 前 面 所 说 的 ， 在 实 模式 下 ，CPU 只 能 使 用 16 位 的 通用 寄存 器 。16 位 寄存 器 能 够 表 
达 的 最 大 数值 是 : gxffff ， 所 以 按照 上 面 的 公式 计算 出 的 最 大 物理 地 址 是 : 


>>> hex(( * 16) + ) 
'Ox10Ffef ' 


这 个 地 址 在 8086 处 理 器 下 ， 将 被 转换 成 地 址 gxgffef ,原因 是 因为 ，8086 cpu 只 有 20 位 地 
址 线 ， 只 能 表示 2020 = imp 的 地 址 ， 而 上 面 这 个 地 址 已 经 超出 了 1MB 地 址 的 范围 ， 所 以 


CPU 就 舍弃 了 最 高 位 。 
实 模式 下 的 1MB 地 址 空间 分 配 表 : 
0x00000000 - 0x000003FF - Real Mode Interrupt Vector Table 
0x00000400 - 0x000004FF - BIOS Data Area 
©x00000500 - Ox00007BFF - Unused 
0x00007C00 - 0x00007DFF - Our Bootloader 
0x00007E00 - 0x0009FFFF - Unused 
Qx000A0000 - OXOOOBFFFF - Video RAM (VRAM) Memory 
0x000B0000 - Ox000B7777 - Monochrome Video Memory 
0x000B8000 - OxOOOBFFFF - Color Video Memory 
Q©x000CO000 - 0x000C7FFF - Video ROM BIOS 
0x000C8000 - OXxOOOEFFFF - BIOS Shadow Area 
OxOOOFO000 - OXOOOFFFFF - System BIOS 
如 果 你 的 记性 不 错 ， 在 看 到 这 张 表 的 时 候 ， 一 定 会 跳出 来 一 个 问题 。 在 上 面 的 章节 中 ， 我 说 


CPU 执行 的 第 
么 实 模式 下 的 CPU 是 如 何 访 问 到 这 


一 条 指令 是 在 地 址 gxFFFFFFF6 处 ， 这 个 地 址 远 远大 于 exFFFFF ( 1MB ) 。 
文 个 地 址 的 呢 ?文档 coreboot 给 出 了 答案 : 


OxFFFE_0000 - OxFFFF_FFFF: 128 kilobyte ROM mapped into address space 


这 个 地 址 被 映射 到 了 ROM? Ath CPU 执行 的 第 一 条 指令 来 自 于 ROM ATÆ 


OxFFFFFFFO 
RAM 。 


引导 程 友 


PAETI > £2 a Linux 系统 
Linux 内 核 通 过 Boot protocol 来 定义 应 该 如 何 实现 引导 程序 。 在 这 


部， 有 多 种 引导 程序 可 以 选择 。 比 如 GRUB 2 和 syslinux ° 
里 我 们 将 只 介绍 GRUB 2 ° 


现在 BIOS 已 经 选择 了 一 个 启动 设备 ， 并 且 将 控制 权 转 移 给 了 启动 局 区 中 的 代码 ， 在 我 们 的 
例子 中 ， 局 动 户 区 代码 是 boot.img。 因 为 这 段 代码 只 能 占用 一 个 扇 区 ， 因 此 非常 简单 ， 只 做 
一 些 必 要 的 初始 化 ， 然 后 就 跳 转 到 GRUB 2's core image 去 执行 。 Core image 的 代码 请 参考 
diskboot.img > —A& Kit core image 在 磁盘 上 存储 在 启动 扁 区 之 后 到 第 一 个 可 用 分 区 之 前 。 
core image 的 初始 化 代码 会 把 整个 core image (包括 GRUB 2 的 内 核 代 码 和 文件 系统 驱动 ) 
引导 到 内 存 中 。 引导 完成 之 后 ，grub_ main 将 被 调用 。 


grub_main 初始 化 控制 台 ， 计 算 模块 基地 址 ， 设 置 root 设备 ， 读 取 grub 配置 文件 ， 加 载 模 
块 。 最 后 ， 将 GRUB 置 于 normal 模式 ， 在 这 个 模式 中 ， 
core/normal/main.c ) 将 被 调用 以 完成 最 后 的 准备 工作 ， 然 后 显示 一 个 菜单 列 出 所 用 可 用 的 操 


grub_normal_execute (from grub- 


作 系 统 。 当 某 个 操作 系统 被 选择 之 后 ， grub_menu_execute_entry 开始 执行 ， 它 将 调用 GRUB 
的 boot 命令 ， 来 引导 被 选中 的 操作 系统 。 


就 像 kernel boot protocol 所 描述 的 ， 引 导 程序 必须 填充 kernel setup header (位 于 kernel 
setup code 偏 移 oxoifa 处 ) 的 必要 字段 。kernel setup header 的 定义 开始 于 
arch/x86/boot/header.S : 


.globl hdr 

hdr: 
setup_sects: .byte 0 
root_flags: .word ROOT_RDONLY 


syssize: .long 0 
ram_size: -word 0 
vid_mode: .Word SVGA_MODE 
root_dev: -word 0 
boot_flag: .Word @xAA55 


bootloader 7 34 È Æ Linux boot protocol 中 标记 为 write 的 头 信息 ， 比 如 

type_of loader， 这 些 头 信 息 可 能 来 自命 令 行 ， 或 者 通过 计算 得 到 。 在 这 里 我 们 不 会 详细 介绍 
所 有 的 kernel setup header， 我 们 将 在 需要 的 时 候 逐 个 介绍 。 不 过 ， 你 可 以 自己 通过 boot 
protocol 来 了 解 这 些 设置 。 


通过 阅读 kernel boot protocol， 在 内 核 被 引导 入 内 存 后 ， 内 存 使 用 情况 将 入 下 表 所 示 : 


| Protected-mode kernel | 


100000 +=+------------------------ + 
| I/0 memory hole | 
0A0000 +------------------------ + 
| Reserved for BIOS | Leave as much as possible unused 
| Command line | (Can also be below the X+10000 mark) 
X+10000 +------------------------ + 
| Stack/heap | For use by the kernel real-mode code. 
X+08000 +------------------------ + 
| Kernel setup | The kernel real-mode code. 
| Kernel boot sector | The kernel legacy boot sector. 
区 十 
| Boot loader | <- Boot sector entry point 0x7C00 
001000 +------------------------ + 
| Reserved for MBR/BIOS | 
000800 r + 
| Typically used by MBR | 
000600 +------------------------ + 
| BIOS use only | 
000000 +------------------------ + 


所 以 当 bootloader 完成 任务 ， 将 执行 权 移 交 给 kernel > kernel 的 代码 从 以 下 地 址 开始 执行 : 


0x1000 + X + sizeof(KernelBootSector) + 1 
个 人 以 为 应 该 是 X + sizeof(KernelBootSector) + 1 AA X 已 经 是 一 个 具体 的 物理 地 址 了 ， 不 是 一 个 偏 移 


上 面 的 公式 中 ， x 是 kernel bootsector 被 引导 入 内 存 的 位 置 。 在 我 的 机 器 上 ， x 的 值 是 
ox10000 ， 我 们 可 以 通过 memory dump 来 检查 这 个 地 址 : 


00010000: 
00010010: 
00010020: 
00010030: 
00010040: Direct floppy bo 
00010050: ot is not suppor 


00010060: ted. Use a boot 
00010070: loader program i 
00010080: nstead....Remove 
00010090: disk and press 
000100a0: any key to reboo 
OIOIONEOIOI TOE A e 2e P a 


到 这 里 ， 引 寻 程 序 完成 它 的 使 命 ， 并 将 控制 权 移 交 给 了 Linux kernel。 下 面 我 们 就 来 看 看 
kernel setup code 都 做 了 些 什么 
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经 过 上 面 的 一 系列 操作 ， 我 们 终于 进入 到 内 核 了 。 不 过 从 技术 上 说 ， 内 核 还 没有 被 运行 起 
来 ， 因 为 首先 我 们 需要 正确 设置 内 核 ， 启 动 内 存 管理 ， 进 程 管理 等 等 。 内 核 设置 代码 的 运行 
起 点 是 arch/x86/boot/header.S 中 定义 的 _start 函数 。 在 _start 函数 开始 之 前 ， 还 有 很 多 
的 代码 ， 那 这 些 代 码 是 做 什么 的 呢 ? 


实际 上 _start 开始 之 前 的 代码 是 kenerl 自 带 的 bootloader。 在 很 久 以 前 ， 是 可 以 使 用 这 个 

bootloader 来 启动 Linux 的 。 不 过 在 新 的 Linux 中 ， 这 个 bootloader 代码 已 经 不 再 启动 Linux 
内 核 ， 而 只 是 输出 一 个 错误 信息 。 如果 你 运行 下 面 的 命令 ， 直 接 使 用 Linux 内 核 来 启动 ， 你 

会 看 到 下 图 所 示 的 错误 : 


qemu-system-x86_64 vmlinuz-3.18-generic 


SeaBIOS (version 1.7.5-20140531_171129-lamiak) 
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Booting from Hard Disk... 
se a boot loader. 


emove disk and press any key to reboot... 





为 了 能 够 作为 bootloader 来 使 用 ，header.,s 开始 处 定义 了 [MZ] MZ 魔术 数字 , 并 且 定 义 了 
头 ， 在 PE 头 中 定义 了 输出 的 字符 串 : 


#ifdef CONFIG_EFI_STUB 
# "MZ", MS-DOS header 
,byte QOx4d 

.byte 0x5a 

#endif 


pe_header: 
„ascii "PE" 
.word 0 


之 所 以 代码 需要 这 样 写 ， 这 个 是 因为 遵从 的 硬件 需要 这 样 的 结构 才能 正常 引导 操作 系 


Bi 9 
去 除 这 些 作 为 bootloader 使 用 的 代码 ， 旦 正 的 内 核 代码 就 从 _start 开始 了 : 


// header.S line 292 
.globl _start 
_start: 


其 他 的 bootloader (grub2 and others) 知道 start 所 在 的 位 置 ( 从 Mz 头 开 始 偏 移 0x200 
字 节 ) ， 所 以 这 些 bootloader 就 会 忽略 所 有 在 这 个 位 置 前 的 代码 (这 些 之 前 的 代码 位 于 
.bstext FAP) ， 直 接 跳 转 到 这 个 位 置 启动 内 核 。 


Vi 

// arch/x86/boot/setup. ld 

Ii 

. = 0; // current position 

,bstext : { *(.bstext) } // put .bstext section to position 0 
,bsdata : { *(.bsdata) } 


.globl _start 
_start: 
.byte Oxeb 
.byte start_of_setup-if 


// 
// rest of the header 
// 


_start 开始 就 是 一 个 jmp 724) ( jmp 784749 opcode 是 gxeb ) ， 这 个 跳 转 语句 是 一 个 
短 跳 转 ， 跟 在 后 面 的 是 一 个 相对 地 址 ( start_of_setup - 1f ) 。 在 汇编 代码 中 Nf RAT 
当前 代码 之 后 第 一 个 标号 为 N 的 代码 段 的 地 址 。 回 到 我 们 的 代码 ， 在 start 标号 之 后 的 
第 一 个 标号 为 1 的 代码 段 中 包含 了 剩 下 的 setup header 结构 。 在 标号 为 1 的 代码 段 结束 
之 后 ， 紧 接着 就 是 标号 为 start_of_setup 的 代码 段 (这 个 代码 段位 于 .entrytext 代码 

区 ， 这 个 代码 段 中 的 第 一 条 指令 实际 上 是 内 核 开始 执行 之 后 的 第 一 条 指令 ) 。 


下 面 让 我 们 来 看 一 下 GRUB2 的 代码 是 如 何 跳 转 到 _start 标号 处 的 。 从 Linux 内 核 代 码 
中 ， 我 们 知道 start 标号 的 代码 位 于 偏 移 ox200 处 。 在 GRUB2 的 源 代 码 中 我 们 可 以 看 到 
下 面 的 代码 : 


state.gs = state.fs = state.es = state.ds = state.ss = segment; 
state.cs = segment + 0x20; 


在 我 的 机 器 上 ， 因 为 我 的 内 核 代 码 被 加 载 到 了 内 存 地 址 oxi99000 处 ， 所 以 在 上 面 的 代码 执行 
完成 之 后 cs = 6x1620 ( 因此 第 一 条 指令 的 内 存 地 址 将 是 cs << 4 + 0 = 0x10200 ， 刚 好 是 
ox10000 开始 后 的 ox200 处 的 指令 ) 


fs = es = ds = ss = 0x1000 
cs = 0x1020 


从 start_of_setup 标号 开始 的 代码 需要 完成 下 面 这 些 事情 : 


o 将 所 有 段 寄 存 器 的 值 设 置 成 一 样 的 内 容 
o 设置 堆栈 

e 设置 bss (静态 变量 区 ) 

e 跳 转 到 main.c 开始 执行 代码 


Rae Bike 


在 代码 的 一 开始 ， 就 将 ds 和 es 段 寄 存 器 的 内 容 设 置 成 一 样 ， 并 且 使 用 指令 sti 来 允许 
FHRA: 


movw %ds, %ax 
movw %ax, %es 
sti 


就 像 我 在 上 面 一 节 中 所 写 的 ， 为 了 能 够 跳 转 到 start 标号 出 执行 代码 ，grub2 将 cs KF 
存 器 的 值 设 置 成 了 gx1020 ， 这 个 值 和 其 他 段 寄存 器 都 是 不 一 样 的 ， 因 此 下 面 的 代码 就 是 将 
cs 段 寄存 器 的 值 和 其 他 段 寄 存 器 一 致 : 


pushw %ds 
pushw $6f 
lretw 


上 面 的 代码 使 用 了 一 个 小 小 的 技巧 来 重 置 cs 寄存 器 的 内 容 ， 下 面 我 们 就 来 仔细 分 析 。 这 段 
aia ds 寄存 器 的 值 入 栈 ， 然 后 将 标号 为 6 的 代码 段 地 址 入 栈 ， 接 着 执行 lretw 48 
令 ， 这 条 指令 ， 将 把 标号 为 6 的 内 存 地 址 放 入 ip 寄存 器 (instruction pointer) ， 将 ds 
寄存 器 的 值 放 入 cs 寄存 器 。 这样 一 来 ds 和 cs 段 寄 存 器 就 拥有 了 相同 的 值 。 


受 置 堆栈 


绝 大 部 分 的 setup 代码 都 是 为 C 语言 运行 环境 做 准备 。 在 设置 了 ds 和 es 寄存 器 之 后 ， 
接 下 来 step 的 代码 将 检查 ss 寄存 器 的 内 容 ， 如 果 寄 存 器 的 内 容 不 对 ， 那 么 将 进行 更 正 : 


movw %SS, %dx 
cmpw %ax, %dx 
movw %sp, %dx 
je 2f 


当 进 入 这 段 代 码 的 时 候 ， ss 寄存 器 的 值 可 能 是 一 下 三 种 情况 之 一 : 


e ss 寄存 器 的 值 是 0x10000 ( 和 其 他 除了 cs 寄存 器 之 外 的 所 有 寄存 器 的 一 样 ) 
e ss 寄存 器 的 值 不 是 0X10000， 但 是 caN_USE_HEAP 标志 被 设置 了 
e ss 寄存 器 的 值 不 是 0x10000， 同 时 cAN_USE_HEAP 标志 没有 被 设置 


下 面 我 们 就 来 分 析 在 这 三 中 情况 下 ， 代 码 都 是 如 何 工作 的 : 


e ss 寄存 器 的 值 是 0X10000， 在 这 种 情况 下 ， 代 码 将 直接 跳 转 到 标号 为 2 的 代码 处 执 
行 : 


2: andw $~3, %dx 
jnz 3f 
movw $oxfffc, %dx 
3: movw %ax, %SS 
movzwl %dx, %esp 
sti 


这 段 代码 首先 将 dx 寄存 器 的 值 (就 是 当前 sp 寄存 器 的 值 ) 4 字 节 对 齐 ， 然 后 检查 是 否 为 
0 (如 果 是 0， 堆 栈 就 不 对 了 ， 因 为 堆栈 是 从 大 地 址 向 小 地 址 发 展 的 ) ， 如 果 是 0， 那 么 就 将 
dx 寄存 器 的 值 设置 成 gxfffc (64KB 地 址 段 的 最 后 一 个 4 字 节 地 址 ) 。 如 果 不 是 0， 那 么 就 
保持 当前 值 不 变 。 接 下 来 ， 就 将 ax 寄存 器 的 值 ( 0x10000 ) 设置 到 ss 寄存 器 ， 并 根据 
dx 寄存 器 的 值 设 置 正 确 的 sp 。 这 样 我 们 就 得 到 了 正确 的 堆栈 设置 ， 具 体 请 参考 下 图 : 


esp 


_end 


Kernel setup 





Kernel legacy boot sector (4d 5a) %ss - 0x10000 


© 下 面 让 我 们 来 看 ss I= ds 的 情况 ， 首 先 将 setup code 的 结束 地 址 end SA dx FH 
器 。 然 后 检查 loadflags 中 是 否 设置 了 CAN_USE_HEAP 标志 。 根据 kernel boot protocol 
的 定义 ，loadflags 是 一 个 标志 字段 。 这 个 字段 的 Bit 7 就 是 CAN_USE_HEAP 标志 : 


Field name: loadflags 
This field is a bitmask. 
Bit 7 (write): CAN_USE_HEAP 
Set this bit to 1 to indicate that the value entered in the 


heap_end_ptr is valid. If this field is clear, some setup code 
functionality will be disabled. 


loadflags 字段 其 他 可 以 设置 的 标志 包括 : 


#define LOADED_HIGH (1<<0) 
#define QUIET_FLAG (1<<5) 
#define KEEP_SEGMENTS (1<<6) 
#define CAN_USE_HEAP (1<<7) 
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从 引导 加 载 程序 内 核 


如 果 CAN_USE_HEAP 被 置 位 ， 那 么 将 heap end_ptr 放 入 dx 寄存 器 ， 然 后 加 上 stack_size 

(最 小 堆栈 大 小 是 512 bytes) 。 在 加 法 完成 之 后 ， 如 果 结 果 没 有 溢出 (CF flag 没有 置 位 ， 

如 果 置 位 那么 程序 就 出 错 了 ) ， 那 么 就 跳 转 到 标号 为 2 的 代码 处 继续 执行 (这 段 代码 的 逻辑 
在 1 中 已 经 详细 介绍 了 ) ， 接 着 我 们 就 得 到 了 如 下 图 所 示 的 堆栈 : 


esp -0xfffc 
_end 
Kernel setup 
Kernel legacy boot sector (4d 5a) %ss, Wds ...- 0x10000 





o 最 后 一 种 情况 就 是 CAN_USE_HEAP 没有 置 位 ， 那 么 我 们 就 将 dx 寄存 器 的 值 加 上 
STACK_SIZE ， 然 后 跳 转 到 标号 为 2 的 代码 处 继续 执行 ， 接 着 我 们 就 得 到 了 如 下 图 所 示 
的 堆栈 : 


esp: end+STACK SIZE 


_end 


Kernel setup 





Kernel legacy boot sector (4d 5a) %ss - 0x10000 


BSSR E 

在 我 们 正式 执行 C 代码 之 前 ， 我 们 还 有 2 件 事情 需要 完成 。1) 设置 正确 的 BSS 段 ; 2) 检查 
magic 签名 。 接 下 来 的 代码 ， 首 先 检 查 magic 签名 setup_sig， 如 果 签 名 不 对 ， 直 接 跳 转 到 
setup_bad 部 分 执行 代码 : 


cmpl $0x5a5aaa55, setup_sig 
jne setup_bad 


如 果 magic 签名 是 对 的 ， 那 么 我 们 只 要 设置 好 Bss 段 ， 就 可 以 开始 执行 C 代码 了 。 
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从 引导 加 载 程序 内 核 


BSS 段 用 来 存储 那些 没有 被 初始 化 的 静态 变量 。 对 于 这 个 段 使 用 的 内 存 ，Linux 首先 使 用 下 
面 的 代码 将 其 全 部 清 零 : 


movw $ _bss_start, %di 
movw $_end+3, %cx 

xorl %eax, %eax 

subw %di, %CXx 

shrw $2, %CX 

rep; stosl 


在 这 段 代码 中 ， 首 先 将 bss start MHRA di 寄存 器 ， 然 后 将 _end + 3 (4 字 节 对 齐 ) 
地 址 放 入 cx ， 接 着 使 用 xor 指令 将 ax 寄存 器 清 零 ， 接 着 计算 BSS 段 的 大 小 ( ex- 
di ) ， 然 后 将 大 小 放 入 cx 寄存 器 。 接 下 来 将 cx 寄存 器 除 4， 最 后 使 用 rep; stosl 指 
令 将 ax 寄存 器 的 值 (0) 写 入 寄存 器 整个 BSS 段 。 代码 执行 完成 之 后 ， 我 们 将 得 到 如 下 
图 所 示 的 BSS Ft: 


_end 


BSS section 
__bss_ start 


Kernel setup 


Kernel legacy boot sector (4d 5a) 


%ss - 0x10000 





跳 转 到 main 4 žr 


到 目前 为 止 ， 我 们 完成 了 堆栈 和 BSS 的 设置 ， 现 在 我 们 可 以 正式 跳 入 main() 函数 来 执行 C 
代码 了 : 


calll main 


main() 函数 定义 在 arch/x86/boot/main.c， 我 们 将 在 下 一 章 详细 介绍 这 个 函数 做 了 什么 事 


情 o 


结束 语 


24 


本 章 到 此 结束 了 ， 在 下 一 章 中 我 们 将 详细 介绍 在 Linux 内 核 设 置 过 程 中 调用 的 第 一 个 C 代码 
( main() ) ， 也 将 介绍 诸如 memset ， memcpy , earlyprintk 这 些 底层 函数 的 实现 ， ata A 


待 。 
如 果 你 有 任何 的 问题 或 者 建议 ， 你 可 以 留言 ， 也 可 以 直接 发 消息 给 我 twitter 。 


如 果 你 发 现 文中 描述 有 任何 问题 ， 请 提交 一 个 PR 到 linux-insides-zh ° 


相关 链接 


e Intel 80386 programmer's reference manual 1986 
e Minimal Boot Loader for Intel® Architecture 
e 8086 

e 80386 

e Reset vector 

e Real mode 

e Linux kernel boot protocol 

e CoreBoot developer manual 

e Ralf Brown's Interrupt List 

e Power supply 

e Power good signal 
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在 内 核 安 装 代 码 的 第 一 


内 核 尼 动 的 第 一 步 


在 上 一 节 中 我 们 开始 接触 到 内 核 启动 代码 ， 并 且 分 析 了 初始 化 部 分 ， 最 后 我 们 停 在 了 
对 main 函数 ( main 函数 是 第 一 个 用 C 写 的 函数 ) 的 调用 ( main 函数 位 于 
arch/x86/boot/main.c) ° 


在 这 一 节 中 我 们 将 继续 对 内 核 启 动 过 程 的 研究 ， 我 们 将 


@ 认识 保护 模式 

o 如 何 从 实 模式 进入 保护 模式 

o 推 和 控制 台 初 始 化 

© 内 存 检测 ，cpu 验 证 ， 键 盘 初 始 化 
e 还 有 更 多 


现在 让 我 们 开始 我 们 的 旅程 


保护 模式 


在 操作 系统 可 以 使 用 Intel 64 位 CPU 的 长 模式 之 前 ， 内 核 必 须 首 先 将 CPU 切换 到 保护 模式 运 
行 。 

什么 是 保护 模式 ? 保护 模式 于 1982 年 被 引入 到 Intel CPU 家 族 ， 并 且 从 那 之 后 ， 直 到 Intel 64:4 
现 ， 保 护 模式 都 是 Intel CPU 的 主要 运行 模式 。 


淘汰 实 模式 的 主要 原因 是 因为 在 实 模式 下 ， 系 统 能 够 访问 的 内 存 非 常 有 限 。 如 果 你 还 记得 我 
们 在 上 一 节 说 的 ， 在 实 模式 下 ， 系 统 最 多 只 能 访问 1M 内 存 ， 而 且 在 很 多 时 候 ， 实 际 能 够 访问 
的 内 存 只 有 640K 。 

保护 模式 带 来 了 很 多 的 改变 ， 不 过 主要 的 改变 都 集中 在 内 存 管 理 方法 。 在 保护 模式 中 ， 实 模 
he 因此 系统 可 以 访问 多 达 4GB 的 地 址 空间 。 另 外 ， 在 保 
护 模 式 中 引入 了 内 存 分 页 功能 ， 在 后 面 的 章节 中 我 们 将 介绍 这 个 功能 。 

保护 模式 提供 了 2 种 完全 不 同 的 内 存 管理 机 制 : 


e 段 式 内 存 管理 
。 内 存 分 页 


在 这 一 节 中 ， 我 们 只 介绍 段 式 内 存 管 理 ， 内 存 分 页 我 们 将 在 后 面 的 章 


> 


在 上 一 节 中 我 们 说 过 ， 在 实 模式 下 ， 一 个 物理 地 址 是 由 2 个 部 分 组 成 的 : 


o 内 存 段 的 基地 址 
© 从 基地 址 开始 的 偏 移 


使 用 这 2 个 信息 ， 我 们 可 以 通过 下 面 的 公式 计算 出 对 应 的 物理 地 址 


PhysicalAddress = Segment * 16 + Offset 


在 保护 模式 中 ， 内 存 段 的 定义 和 实 模式 完全 a sn 每 个 内 存 段 不 再 是 64K 大 
小 ， 段 的 大 小 和 起 始 位 置 是 通过 一 个 叫做 段 描述 符 的 数据 结构 进行 描述 。 所 有 内 存 段 的 段 描 述 
符 存储 在 一 个 叫做 全 局 描述 符 表 (GDT) 的 内 存 结构 中 。 


AMAR 这 个 内 存 数据 结构 在 内 存 中 的 位 置 并 不 是 固定 的 ， 它 的 地 址 保存 在 一 个 特殊 寄存 
器 corr 中 。 在 后 面 的 章节 中 ， 我 们 将 在 Linux 内 核 代 码 中 看 到 全 局 描述 符 表 的 地 址 是 如 何 被 
保存 到 GDTR 中 的 。 具 体 的 汇编 代码 看 起 来 是 这 样 的 : 


lgdt gdt 


lgdt 人 保存 到 GDTR 寄存 器 中 。 GDTR 是 一 个 48 
位 的 寄存 器 ， 这 个 寄存 器 中 的 保存 了 2 部 分 的 内 容 : 


o 全 局 描述 符 表 的 大 小 (16 位 ) 
。 全 局 描述 符 表 的 基 址 (32 位 ) 


就 像 前 面 的 段落 说 的 ， 全 局 描述 符 表 包含 了 所 有 内 存 段 的 段 描述 符 。 每 个 段 描述 符 长 度 是 64 
位 ， 结 构 如 下 图 描述 : 


31 24 19 16 7 0 

| | IB] IAI | | | 19lEIWIAI | 

| BASE 31:24 |G|/|L|V| LIMIT |P|DPL|S| TYPE | BASE 23:16 | 4 
| | ID] IL] 19:16 | | | ICIRIAI | 

| | 


| 
| BASE 15:0 | LIMIT 15:0 | 0 
| 


粗 粗 一 看 ， 上 面 的 结构 非常 吓人 ， 不 过 实际 上 这 个 结构 是 非常 容易 理解 的 。 比 如 在 上 图 中 的 
LIMIT 15:0 表示 这 个 数据 结构 的 0 到 15 位 保存 的 是 内 存 段 的 大 小 的 0 到 15 位 。 相 似 的 LIMITE 
19:16 表示 上 述 数据 结构 的 16 到 19 位 保存 的 是 内 存 段 大 小 的 16 到 19 位 。 从 这 个 分 析 中 ， 我 们 
可 以 看 出 每 个 内 存 段 的 大 小 是 通过 20 位 进行 描述 的 。 下 面 我 们 将 对 这 个 数据 结构 进行 仔细 分 

析 : 


1. P ea 被 保存 在 上 述 内 存 结构 的 0-15 和 16-19 位 。 根 据 上 述 内 存 结构 中 6 位 的 设 
置 ， 这 20 位 内 存 定义 的 内 存 长 度 是 不 一 样 的 。 下 面 是 一 些 具 体 的 例子 : 


o 如 果 6 =0, 并 且 Limit=0， 那 么 表示 段 长 度 是 1 byte 

o 如 果 c =1, 并 且 Limit=0, 那么 表示 段 长 度 是 4K bytes 

o 如 果 e =0， 并 且 Limit = 0xffff， 那 么 表示 段 长 度 是 1M bytes 

o 如 果 6 =1， 并 且 Limit = Oxffff， 那 么 表示 段 长 度 是 4G bytes 
从 上 面 的 例子 我 们 可 以 看 出 : 


o 如 果 G = 0, 那么 内 存 段 的 长 度 是 按照 1 byte 进 行 增长 的 ( Limit 每 增加 1， 段 长 度 增加 1 
byte )， 最 大 的 内 存 段 长 度 将 是 1M bytes ; 
o 如 果 G = 1, 那么 内 存 段 的 长 度 是 按照 4K bytes 进 行 增长 的 (Limit 每 增加 1， 段 长 度 增 
加 4K bytes )， 最 大 的 内 存 段 长 度 将 是 4G bytes; 
o 段 长 度 的 计算 公式 是 base_seg length * (LIMIT + 1)。 
2. Base[32-bits] 被 保存 在 上 述 地 址 结构 的 0-15 ，32-39 以 及 56-63 位 。Base 定 义 了 段 基 址 。 


3. Type/Attribute (40-47 bits) 定义 了 内 存 段 的 类 型 以 及 支持 的 操作 。 


o s 标记 ( 第 44 位 ) 定义 了 段 的 类 型 ，s = 0 说 明 这 个 内 存 段 是 一 个 系统 段 ; s = 
1 说 明 这 个 内 存 段 是 一 个 代码 段 或 者 是 数据 段 ( 堆栈 段 是 一 种 特殊 类 型 的 数据 段 ， 堆 
栈 段 必须 是 可 以 进行 读 写 的 段 ) 。 


在 s = 1 的 情况 下 ， 上 述 内 存 结构 的 第 43 位 决定 了 内 存 段 是 数据 段 还 是 代码 段 。 如果 43 位 = 
0， 说 明 是 一 个 数据 段 ， 否 则 就 是 一 个 代码 段 。 


对 于 数据 段 和 代码 段 ， 下 面 的 表格 给 出 了 段 类 型 定义 


| Type Field | Descriptor Type | Description 
人 1 1 

| Decimal | | 

| 9 E w AI | 

| 9 0 0 0 © | Data | Read-Only 

| 1 0 0 0 1 | Data | Read-Only, accessed 

2 0 0 1 © | Data | Read/Write 

| 3 0 0 1 1 | Data | Read/Write, accessed 

| 4 0 1 0 © | Data | Read-Only, expand-down 

| & 0 1 0 1 | Data | Read-Only, expand-down, accessed 
| 6 0 1 1 © | Data | Read/Write, expand-down 

| 7 0 1 1 1 | Data | Read/Write, expand-down, accessed 
| c R AJ] | 

| 8 1 0 0 © | Code | Execute-Only 

| 9 1 0 0 1 | Code | Execute-Only, accessed 

| 10 1 0 al © | Code | Execute/Read 

| 12 1 0 1 1 | Code | Execute/Read, accessed 

| 12 1 1 0 © | Code | Execute-Only, conforming 

| 14 1 1 0 1 | Code | Execute-Only, conforming, accessed 
| 13 1 1 1 © | Code | Execute/Read, conforming 

| 15 1 1 1 1 | Code | Execute/Read, conforming, accessed 


从 上 面 的 表格 我 们 可 以 看 出 ， 当 第 43 位 是 o 的 时 候 ， 这 个 段 描述 符 对 应 的 是 一 个 数据 段 ， 如 
果 该 位 是 1， 那么 表示 这 个 段 描述 符 对 应 的 是 一 个 代码 段 。 对 于 数据 段 ， 第 42，41，40 位 表 
THAER’ WTS ATH) ; 对 于 代码 段 ， 第 42，41，40 位 表示 的 是 (C 一 致 ， 尺 可 
读 ，A 可 访问 ) 。 


e 如 果 E = 0， 数 据 段 是 向 上 扩展 数据 段 ， 反 之 为 向 下 扩展 数据 段 。 关 于 向 上 扩展 和 向 下 
扩展 数据 段 ， 可 以 参考 下 面 的 链接 。 在 一 般 情况 下 ， 应 该 是 不 会 使 用 向 下 扩展 数据 段 
的 。 

e 如 果 Ww = 1， 说 明 这 个 数据 段 是 可 写 的 ， 否 则 不 可 写 。 所 有 数据 段 都 是 可 读 的 。 

© A 位 表示 该 内 存 段 是 否 已 经 被 CPU 访问 。 

e 如 果 c = 1， 说 明 这 个 代码 段 可 以 被 低 优先 级 的 代码 访问 ， 比 如 可 以 被 用 户 态 代 码 访 
问 。 反 之 如 果 c =0， 说 明 只 能 同 优先 级 的 代码 段 可 以 访问 。 

e 如果 R = 1， 说 明 该 代码 段 可 读 。 代 码 段 是 永远 没有 写 权 限 的 。 


1. DPL (2-bits, bit 45 和 46) 定义 了 该 段 的 优先 级 。 具 体 数 值 是 0-3。 


2. P 标 志 (bit 47) - 说 明 该 内 存 段 是 否 已 经 存在 于 内 存 中 。 如 果 P = 0， 那 么 在 访问 这 个 内 
存 段 的 时 候 将 报错 。 


3. AVL 标志 (bit 52) - 这 个 位 在 Linux 内 核 中 没有 被 使 用 。 


4. 上 标志 (bit 53) - 只 对 代码 段 有 意义 ， 如 果 L = 1， 说 明 该 代码 段 需要 运行 在 64 位 模式 
Fo 


5. D/B flag(bit 54) - 根据 段 描 述 符 描述 的 是 一 个 可 执行 代码 段 、 下 扩 数 据 段 还 是 一 个 堆栈 
段 ， 这 个 标志 具有 不 同 的 功能 。 (对 于 32 位 代码 和 数据 段 ， 这 个 标志 应 该 总 是 设置 为 1 ; 
对 于 16 位 代码 和 数据 段 ， 这 个 标志 被 设置 为 0。) 。 


o 可 执行 代码 段 。 此 时 这 个 标志 称 为 DD 标志 并 用 于 指出 该 段 中 的 指令 引用 有 效 地 址 和 操 
作 数 的 默认 长 度 。 如 果 该 标志 置 位 ， 则 默认 值 是 32 位 地 址 和 32 位 或 8 位 的 操作 数 ; 如 
果 该 标志 为 0， 则 默认 值 是 16 位 地 址 和 16 位 或 8 位 的 操作 数 。 指 令 前 级 0x66 可 以 用 来 
选择 非 默 认 值 的 操作 数 大 小 ; 前 级 0x67 可 用 来 选择 非 默 认 值 的 地 址 大 小 。 
o RE (由 SS 寄存 器 指向 的 数据 段 )。 此 时 该 标志 称 为 B (Big) 标志 ， 用 于 指明 隐 含 
堆栈 操作 (如 PUSH、POP 或 CALL) 时 的 栈 指针 大 小 。 如 果 该 标志 置 位 ， 则 使 用 32 
位 栈 指针 并 存放 在 ESP 寄 存 器 中 ; 如 果 该 标志 为 0， 则 使 用 16 位 栈 指针 并 存放 在 SP 
寄存 器 中 。 如 果 堆 栈 段 被 设置 成 一 个 下 扩 数 据 段 ， 这 个 B 标 志 也 同时 指定 了 堆栈 段 的 
上 界限 。 
o 下 扩 数 据 段 。 此 时 该 标志 称 为 B 标 志 ， 用 于 指明 堆栈 段 的 上 界限 。 如 果 设 置 了 该 标 
志 ， 则 堆栈 段 的 上 界限 是 0xFFFFFFFF (4GB) ; 如 果 没 有 设置 该 标志 ， 则 堆栈 段 
的 上 界限 是 0xFFFF (64KB) ° 
在 保护 模式 下 ， 段 寄存 器 保存 的 不 再 是 一 个 内 存 段 的 基地 址 ， 而 是 一 个 称 为 段 选择 子 的 结构 。 
每 个 段 描 述 符 都 对 应 一 个 段 选 择 子 。 段 选择 子 是 一 个 16 位 的 数据 结构 ， 下 图 显示 了 这 个 数据 结 
构 的 内 容 : 


。 Index 表示 在 GDT 中 ， 对 应 段 描述 符 的 索引 号 。 
。 TI 表示 要 在 GDT 还 是 LDT 中 查找 对 应 的 段 描 述 符 
。 RPL 表示 请 求 者 优先 级 。 这 个 优先 级 将 和 段 描述 符 中 的 优先 级 协同 工作 ， 共 同 确定 访问 


是 否 合法 。 


在 保护 模式 下 ， 每 个 段 寄 存 器 实际 上 包含 下 面 2 部 分 内 容 : 


T 
。 隐藏 部 分 - 段 描述 符 
在 保护 模式 中 ，cpu 有 是 通过 下 面 的 步骤 来 找到 一 个 具体 的 物理 地 址 的 : 


。 代码 必须 将 相应 的 段 选择 子 装 入 某 个 段 寄 存 器 

。 CPU 根据 段 选择 子 从 GDT 中 找到 一 个 匹配 的 段 描述 符 ， 然 后 将 段 描述 符 放 入 段 寄存 器 的 
隐藏 部 分 

。 在 没有 使 用 向 下 扩展 段 的 时 候 ， 那 么 内 存 段 的 基地 址 就 是 段 描述 符 中 的 基地 址 ， 段 描述 符 
的 limit + 1 就 是 内 存 段 的 长 度 。 如 果 你 知道 一 个 内 存 地 址 的 偏 黎 ， 那 么 在 没有 开启 分 


页 机 制 的 情况 下 ， 这 个 内 存 的 物理 地 址 就 是 基地 址 + 偏 移 






Selector 






当代 码 要 从 实 模式 进入 保护 模式 的 时 候 ， 需 要 执行 下 面 的 操作 : 





e 禁止 中 断 发 生 

e 使 用 命令 lgt 将 GDT 表 装 入 cor 寄存 器 

© 设置 CR0 寄 存 器 的 PE 位 为 1， 使 CPU 进 入 保护 模式 

© 跳 转 开 始 执行 保护 模式 代码 
在 后 面 的 章节 中 ， 我 们 将 看 到 Linux 内 核 中 完整 的 转换 代码 。 不 过 在 系统 进入 保护 模式 之 前 ， 
内 核 有 很 多 的 准备 工作 需要 进行 。 
让 我 们 打开 C 文 件 arch/x86/boot/main.c。 这 个 文件 包含 了 很 多 的 函数 ， 这 些 函 数 分 别 会 执行 
键盘 初始 化 ， 内 存 堆 初始 化 等 等 操作 ..…， 下 面 让 我 们 来 具体 看 一 些 重要 的 函数 。 


将 尼 动 参数 拷贝 到 "zeropage" 


让 我 们 从 main BRA AA KS BAH > BAMA T copy_boot_params(void) ° 


HBA A KIL B15 4 NF) poot_params 结构 的 相应 字段 。 大 家 可 以 
ee boot_params 结构 的 定义 。 


struct setup_header hdr 字段 。 这 个 结构 包含 了 linux boot protocol 
。 在 内 核 编 译 的 时 候 copy_boot_params 完成 两 个 


boot_params 结构 中 包 
中 定义 的 相同 字段 ， ee loader 填 写 
LAG 


1. 将 headerS 中 定义 的 har 结构 中 的 内 容 拷贝 到 结构 的 字段 struct 


setup_header hdr 中 。 


boot_params 


2. 如 果 内 核 是 通过 老 的 命令 行 协议 运行 起 来 的 ， 那 么 就 更 新 内 核 的 命令 行 指针 。 
这 里 需要 注意 的 是 拷贝 hdr 数据 结构 的 memcpy 函数 不 是 C 语 言 中 的 有 函 是 定义 在 


copy.S。 让 我 们 来 具体 分 析 一 下 这 上 段 代码 : 


GLOBAL (memcpy ) 
pushw %si ;push si to stack 
pushw %di ;push di to stack 
movw %ax, %di ;move &boot_param.hdr to di 
movw %dx, %si ;move &hdr to si 
pushw %CX ;push cx to stack ( Sizeof(hdr) ) 
shrw $2, %CX 
rep; movsl ;copy based on 4 bytes 
popw %CX ;pop cx 
andw $3, %CxX ;Cx = cx % 4 
rep; movsb ;copy based on one byte 
popw %di 
popw %si 
retl 
ENDPROC ( memcpy) 


在 copy.s 文件 中 ， 你 可 以 看 到 所 有 的 方法 都 开始 于 GLOBAL 宏 定义 ， 而 结束 于 ENDPROC 宏 


定义 。 


你 可 以 在 arch/x86/include/asm/linkage.h 中 找到 


个 名 字 标 签 ， 并 且 让 这 个 名 字 全 局 可 用 。 


#define GLOBAL(name) 
.globl name; 


name: 


你 可 以 在 includellinux/linkage.h 中 找到 ENDPROC 宏 的 定 
数 的 结束 ， 同 时 将 函数 名 输出 ， 从 而 静态 


R TIE B 


GLOBAL 宏 定 义 。 这 个 宏 给 


义 。 这 个 宏 通 过 
分 析 工 具 可 以 找到 这 


合 代码 段 分 配 了 一 


代码 标 


#define ENDPROC(name) \ 
.type name, @function ASM_NL \ 
END (name) 


memcpy 的 实现 代码 是 很 容易 理解 的 。 首 先 ， 代 码 将 si 和 di 寄存 器 的 值 压 入 堆栈 进行 保 
存 ， 这 么 做 的 原因 是 因为 后 续 的 代码 将 修改 si 和 di 寄存 器 的 值 。 memcpy 函数 (也 包括 
其 ee) He BH) 使 用 了 fastcall 调用 规则 ， 意 味 着 所 有 的 函数 调用 参数 是 
通过 ax, dx, cx 寄存 器 传 入 的 ， 而 不 是 传统 的 通过 堆栈 传 入 。 因 此 在 使 用 下 面 的 代码 调用 
memcpy % žr 6y It 4% 


memcpy(&boot_params.hdr, &hdr, sizeof hdr); 


函数 的 参数 是 这 样 传递 的 


@ ax 寄存 器 指向 boot_param.hdr 的 内 存 地 址 
e dx 寄存 器 指向 har 的 内 存 地 址 
e cx 寄存 器 包含 hdr 结构 的 大 小 


memcpy 函数 在 将 si 和 di 寄存 器 压 栈 之 后 ， 将 boot_param.hdr 的 地 址 放 入 di 寄存 
器 ， 将 hdr 的 地 址 放 入 si 寄存 器 ， 并 且 将 hdr 数据 结构 的 大 小 压 栈 。 接 下 来 代码 首先 
以 4 个 字 节 为 单位 ， 将 si 寄存 器 指向 的 内 存 内 容 拷贝 到 di 寄存 器 指向 的 内 存 。 当 剩 下 的 
字 节 数 不 足 4 字 节 的 时 候 ， 代 码 将 原始 的 hdr 数据 结构 大 小 出 栈 放 入 cx ， 然 后 对 cx 的 
值 对 4 求 模 ， 接 下 来 就 是 根据 cx 的 值 ， 以 字 节 为 单位 将 si 寄存 器 指向 的 内 存 内 容 拷贝 到 
di 寄存 器 指向 的 内 存 。 当 拷贝 操作 完成 之 后 ， 将 保留 的 si 以 及 di 寄存 器 值 出 栈 ， 函 数 
返回 。 


控制 台 初 始 化 


在 hdr 结构 体 被 拷贝 到 poot_params.hdr 成 员 之 后 ， 系 统 接 下 来 将 进行 控制 台 的 初始 化 。 
控制 台 初 始 化 时 通过 调用 arch/x86/boot/early_serial_console.c 中 定义 的 console_init 有 函数 
实现 的 。 


这 个 函数 首先 查看 命令 行 参数 是 否 包 含 earlyprintk 选项 。 如 果 命 令 行 参 数 包 含 该 选项 ， 那 
么 函数 将 分 析 这 个 选项 的 内 容 。 得 到 控制 台 将 使 用 的 串口 信息 ， 然 后 进行 事 口 的 初始 化 。 以 
下 是 earlyprintk 选项 可 能 的 取 值 : 


e Serial,0x3f8,115200 
e Serial,ttyS0,115200 
e ttyS0,115200 


当 串 口 初始 化 成 功 之 后 ， 如 果 命 令 行 参数 包含 debug 选项 ， 我 们 将 看 到 如 下 的 输出 。 


If (cmdline_find_option_bool("debug")) 
puts("early console in setup code\n"); 


puts Mae LEtty.ce KP BAR ef BAVA putchar 函数 将 输入 字符 串 中 的 内 容 按 字 
节 输 出 。 下 面 让 我 们 来 看 看 putchar 函数 的 实现 : 


void __attribute__((section(".inittext"))) putchar(int ch) 


{ 
if (ch == '\n') 
putchar('\r'); 
bios_putchar(ch); 
if (early_serial_base != 0) 
serial_putchar(ch); 
} 


__attribute__((section(".inittext"))) 说 明 这 段 代码 将 被 放 入 .inittext 代码 段 。 关 于 
.inittext 代码 段 的 定义 你 可 以 在 setup.ld 中 找到 。 


如 果 需 要 输出 的 字符 是 n ， 那 么 putchar 函数 将 调用 自己 首先 输出 一 个 字符 r 。 接 下 
来 ， 就 调用 bios_putchar 函数 将 字符 输 出 到 显示 器 (使 用 bios int10 中 BT ) 


static void __attribute_((section(".inittext"))) bios_putchar(int ch) 


{ 


struct biosregs ireg; 


initregs(&ireg); 

ireg.bx = 0x0007; 

ireg.cx = 0x0001; 

ireg.ah = 0x0e; 

ireg.al = ch; 

intcall(0x10, &ireg, NULL); 


在 上 面 的 代码 中 initreg 函数 接受 一 个 biosregs 结构 的 地 址 作为 输入 参数 ， 该 函数 首先 调 
用 memset 函数 将 biosregs 结构 体 所 有 成 员 清 0 S 


memset (reg, 0, sizeof *reg); 
reg->eflags |= X86_EFLAGS CF; 
reg->ds = ds(); 
ds(); 
reg->fs = fs(); 
reg->gs = gs(); 


reg->es 


TALLRIKE AMemset HAH LIM : 


GLOBAL (memset ) 
pushw %di 
movw %ax, %di 
movzbl %dl, %eax 
imull $0x01010101, %eax 
pushw %cx 
shrw $2, %CX 
rep; stosl 
popw %CX 
andw $3, %CX 


rep; stosb 


popw %di 
retl 
ENDPROC ( memset ) 


首先 你 会 发 现 ， memset 函数 和 memcpy 函数 一 样 使 用 了 fastcall 调用 规则 ， 因此 函数 的 
参数 是 通过 ax °? dx 以 及 cx 寄存 器 传 入 函数 内 部 的 。 


就 像 memcpy 有 函数 一 样 > memset 函数 一 开始 将 di HEAR ， 然 后 将 biosregs 结构 的 
地 址 从 ax 寄存 器 拷贝 到 di 寄存 器 。 接 下 来 ， 使 用 movzbl 指令 将 dl 寄存 器 的 内 容 找 贝 
到 ax 寄存 器 的 低 字 节 ， 到 这 里 ax 寄存 器 就 包含 了 需要 拷贝 到 di 寄存 器 所 指向 的 内 存 
的 值 。 


接 下 来 的 imull 指令 将 eax 寄存 器 的 值 乘 上 oxo1010101 。 这 么 做 的 原因 是 代码 每 次 将 尝 
试 拷 贝 4 个 字 节 内 存 的 内 容 。 下 面 让 我 们 来 看 一 个 具体 的 例子 ， 假 设 我 们 需要 将 ox7 这 个 数 
值 放 到 内 存 中 > 在 执行 imull 指令 之 前 ， eax 寄存 器 的 值 是 0x7 ， 在 imull 指令 被 执行 
之 后 ，eax 寄存 器 的 内 容 变 成 了 0x07070707 (4 个 字 节 的 gx7 ) 。 在 imul 指令 之 后 ， 

代码 使 用 rep; stosl 指令 将 eax 寄存 器 的 内 容 拷贝 到 es:di 指向 的 内 存 。 


在 bisoregs 结构 体 被 initregs 函数 正确 填充 之 后 ， bios_putchar 调用 中 断 0x10 在 显示 
器 上 输出 一 | 字符 。 接 下 来 putchar 欧 数 检查 是 否 初 始 化 了 串 a> 如 果 串 口 被 初始 化 了 ， AR 
么 将 调用 serial putchar 将 字符 输出 到 串口 。 


堆 初 始 化 


当 扒 栈 和 bss 段 在 headerS 中 被 初始 化 之 后 (细节 请 参考 上 一 篇 part)， 内 核 需要 初始 化 全 局 
堆 ， 全 局 堆 的 初始 化 是 通过 init heap 函数 实现 的 。 


代码 首先 检查 内 核 设置 头 中 的 loadflags 是 否 设 置 了 CAN_USE_HEAP 标志 。 如 果 该 标记 被 设置 
了 ， 那 么 代码 将 计算 堆栈 的 结束 地 址 : : 


char *stack_end; 


//%P1 is (-STACK_SIZE) 
if (boot_params.hdr.loadflags & CAN_USE_HEAP) { 
asm( "leal %P1(%%esp), %0" 
: "=r" (stack_end) : "i" (-STACK_SIZE)); 


换言之 stack_end = esp - STACK_SIZE . 


ETE THER RAZE RATT T HE E RA : 


//heap_end = heap_end_ptr + 512 
heap_end = (char *)((size_t)boot_params.hdr.heap_end_ptr + 0x200); 


接 下 来 代码 判断 heap_end 是 否 大 于 Stack_end ， 如 果 条 件 成 立 ， 将 Stack_end 设置 成 
heap_end (这 么 做 是 因为 在 大 部 分 系统 中 全 局 堆 和 堆栈 是 相 令 的， 但 是 增长 方向 是 相反 
的 ) 。 


到 这 里 为 止 ， 全 局 堆 就 被 正确 初始 化 了 。 在 全 局 堆 被 初始 化 之 后 ， 我 们 就 可 以 使 用 GET_HEAP 
方法 。 至 于 这 个 函数 的 实现 和 使 用 ， 我 们 将 在 后 续 的 章节 中 看 到 。 


检查 CPU 类 型 


在 堆栈 初始 化 之 后 ， 内 核 代码 通过 调用 arch/x86/boot/cpu.c 提 供 的 _ validate_cpu 方法 检查 
CPU 级 别 以 确定 系统 是 否 能 够 在 当前 的 CPU 上 运行 。 


validate_cpu 调用 了 check cpu 方法 得 到 当前 系统 的 CPU 级 别 ， 并 且 和 系统 预 设 的 最 低 CPU 
级 别 进行 比较 。 如 果 不 满足 条 件 ， 则 不 允许 系统 运行 。 


ZAM COU 

check_cpu(&cpu_level, &req_level, &err_flags); 

/*after check_cpu call, reg_level = req_level defined in cpucheck.c*/ 

if (cpu_level < req_level) { 
printf("This kernel requires an %s CPU, ", cpu_name(req_level)); 
printf("but only detected an %s CPU.\n", cpu_name(cpu_level)); 
returnis T, 


除 此 之 外 ， check cpu 方法 还 做 了 大 量 的 其 他 检测 和 设置 工作 ， 下 面 就 简单 介绍 一 些 : 1) 检 
查 cpu 标 志 ， 如 果 cpu 是 64 位 cpu， 那 么 就 设置 long mode, 2) 检查 CPU 的 制造 商 ， 根 据 制 造 商 
的 不 同 ， 设 置 不 同 的 CPU 选项 。 比 如 对 于 AMD 出 厂 的 cpu， 如 果 不 支持 ssE+SSE2 > MAMA 
止 这 些 选项 。 


内 存 分 布 贷 测 


接 下 来 ， 内 核 调用 detect_memory 方法 进行 内 存 侦 测 ， 以 得 到 系统 当前 内 存 的 使 用 分 布 。 该 
方法 使 用 多 种 编程 接口 ， 包 括 gxe826 (获取 全 部 内 存 分 配 ) > oxesor 和 6x88 (获取 临近 
AGAT) ， 进 行内 存 分 布 侦 测 。 在 这 里 我 们 只 介绍 arch/x86/bootmemory.c 中 提供 的 


detect_memory_e820 方法 。 


该 方法 首先 调用 initregs 方法 初始 化 biosregs 数据 结构 ， 然 后 向 该 数据 结构 填 入 
oxes20 编程 接口 所 要 求 的 参数 : 


initregs(&ireg); 


ireg.ax = 0xe820; 
ireg.cx = sizeof buf; 
ireg.edx = SMAP; 
ireg.di = (size_t)&buf; 


@ ax 定 为 0xe820 

© cx 包含 数据 缓冲 区 的 大 小 ， 该 缓冲 区 将 包含 系统 内 存 的 信息 数据 
e edx 必须 是 sMAP 这 个 魔术 数字 ， 就 是 0x534d4150 

© es:di 包含 数据 缓冲 区 的 地 址 

e ebx 必须 为 0. 


接 下 来 就 是 通过 一 个 循环 来 收集 内 存 信息 了 。 每 个 循环 都 开始 于 一 个 gx15 中 断 调 用 ， 这 个 
中 断 调 用 返回 地 址 分 配 表 中 的 一 项 ， 接 着 程序 将 返回 的 ebx 设置 到 biosregs 数据 结构 中 ， 
然后 进行 下 一 次 的 oxis 中 断 调 用 。 那 么 循环 什么 时 候 结束 呢 ? 直到 ox 调用 返回 的 


eflags 包含 标志 x86_EFLAGS_CF : 


intcall(0xi5, &ireg, &oreg); 
ireg.ebx = oreg.ebx; 


在 循环 结束 之 后 ， 整 个 内 存 分 配 信息 将 被 写 入 到 e820entry 数组 中 ， 这 个 数组 的 每 个 元 素 包 
含 下 面 3 个 信息 : 


o 内 存 段 的 起 始 地 址 
e 内 存 段 的 大 小 
o 内 存 段 的 类 型 (类 型 可 以 是 reserved, usable 等 等 ) 。 


你 可 以 在 dmesg 输出 中 看 到 这 个 数组 的 内 容 : 


.000000] e820: BIOS-provided physical RAM map: 

-000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable 
.000000] BIOS-e820: [mem Ox000000000009FcC00-0x000000000009F FFF] reserved 
.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved 
-000000] BIOS-e820: [mem 0x0000000000100000-0x000000003ffdffff] usable 
.000000] BIOS-e820: [mem 0x000000003ffe0000-0x000000003fffffff] reserved 
.000000] BIOS-e820: [mem 0x00000000F FFc0000-Ox00000000f FFFFFFF] reserved 
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键盘 初始 化 


接 下 来 内 核 调用 keyboard init() 方法 进行 键盘 初始 化 操作 。 首先 ， 方 法 调用 initregs 初始 
化 寄存 器 结构 ， 然 后 调用 0x16 中 断 来 获取 键盘 状态 


initregs(&ireg); 

ireg.ah = 0x02; /* Get keyboard status */ 
intcall(0xi6, &ireg, &oreg); 
boot_params.kbd_status = oreg.al; 


在 获取 了 键盘 状态 之 后 ， 代 码 再 次 调用 0x16 中 断 来 设置 键盘 的 按键 检测 频率 。 


ireg.ax = 0x0305; /* Set keyboard repeat rate */ 
intcall(0xi6, &ireg, NULL); 


系统 参数 查询 
ee aA 绍 所 有 这 些 查询 ， 我 们 将 在 后 
续 章节 中 再 进行 详细 介绍 。 在 这 里 我 们 将 简单 介绍 一 些 系统 参数 查询 


query_mca 方法 调用 0x15 中 断 来 获取 机 器 的 型 号 信息 ，BIOS 版 本 以 及 其 他 一 些 硬件 相关 的 属 
性 : 


int query_mca(void) 


{ 


struct biosregs ireg, oreg; 
U16 len; 


initregs(&ireg); 
ireg.ah = 0xc0; 
intcall(0xi5, &ireg, &oreg); 


if (oreg.eflags & X86_EFLAGS_CF) 
return -1; /* No MCA present */ 


set_fs(oreg.es); 
len = rdfsi6(oreg.bx); 


if (len > sizeof(boot_params.sys_desc_table) ) 
len = sizeof(boot_params.sys_desc_table); 


copy_from_fs(&boot_params.sys_desc_table, oreg.bx, len); 
return or 


这 个 方法 设置 ah 寄存 器 的 值 为 oxco ， 然 后 调用 oxis BIOS 中 断 。 中 断 返 回 之 后 代码 检 
查 carry flag。 如 果 它 被 置 位 ， 说 明 BIOS 不 支持 MCA。 如 果 CF 被 设置 成 0， 那 么 ES:BX 指向 
系统 信息 表 。 这 个 表 的 内 容 如 下 所 示 : 


Offset Size Description 

00h WORD number of bytes following 

02h BYTE model (see #00515) 

03h BYTE submodel (see #00515) 

04h BYTE BIOS revision: © for first release, 1 for 2nd, etc. 
05h BYTE feature byte 1 (see #00510) 
06h BYTE feature byte 2 (see #00511) 
07h BYTE feature byte 3 (see #00512) 
08h BYTE feature byte 4 (see #00513) 
09h BYTE feature byte 5 (see #00514) 
---AWARD BIOS-- - 

OAh N BYTES AWARD copyright notice 

---Phoenix BIOS--- 

OAh BYTE 222? (00h) 

OBh BYTE major version 

OCh BYTE minor version (BCD) 

ODh 4 BYTEs ASCIZ string "PTL" (Phoenix Technologies Ltd) 
---Quadram Quad386-- - 

OAh 17 BYTES ASCII signature string "Quadram Quad386XT" 
---Toshiba (Satellite Pro 435CDS at least)--- 

OAh 7 BYTES Signature "TOSHIBA" 

11h BYTE 222? (8h) 

12h BYTE 222 (E7h) product ID??? (guess) 

13h 3 BYTES "JPN" 


ons 


接 下 来 代码 调用 set_fs THK? HW es 寄存 器 的 值 写 入 fs 寄存 


static inline void set_fs(u16 seg) 


{ 


asm volatile("movw %0,%%fs" : : "rm" (seg)); 


在 boot.h 存在 很 多 类 似 于 setts 的 方法 , 比如 set gs ° 


在 query_mca 的 最 后 ， 代 码 将 es:bx 指向 的 内 存 地 址 的 内 容 找 贝 到 


boot_params.sys_desc_table ° 


接 下 来 ， 内 核 调 用 query_ist 方法 获取 |ntel SpeedStep 人 信息。 这 个 方法 首先 检查 CPU 类 型 ， 
然后 调用 oxis 中 断 获 得 这 个 信息 并 放 入 boot_params 中 。 


接 下 来 ， 内 核 会 调用 query apm_bios 方法 从 BIOS 获 得 高 级 电源 管理 信息 。 query_apm_bios 
也 是 调用 gx15 中 断 ， 只 不 过 将 ax 设置 成 gx5366 以 得 到 APM 设 置信 息 。 中 断 调用 返 

后 ， 代 码 将 检查 bx 和 cx 的 值 ， H bx 不 是 ox504d (PM 标记 )， 或 者 cx 不 是 
gx62 (0Xx02， 表 示 支 持 32 位 模式 )， 那 么 代码 直接 返回 错误 。 否 则 ， 将 进行 下 面 的 步骤 。 


接 下 来 ， 代 码 使 用 ax = 0x5304 来 调用 gx15 中 断 ， 以 断 开 apm 接口 ; 然后 使 用 ax = 
ox5303 调用 gx15 中 断 ， 使 用 32 位 接口 重新 连接 apm ; 最 后 使 用 ax = ox5300 调用 oxis 
中 断 再 次 获取 APM 设 置 ， 然 后 将 信息 写 入 boot_params.apm_bios_info ° 


需要 注意 的 是 ， 只 有 在 CONFIG APM 或 者 CONFIG_APM MODULE 被 设置 的 情况 
下 ， query_apm_bios 方法 才 会 被 调用 : 


#if defined(CONFIG_APM) || defined(CONFIG_APM_MODULE) 
query_apm_bios(); 
#endif 


最 后 是 query edd 方法 调用 , 这 个 方法 从 BIOS 中 查询 Enhanced Disk Drive 人 信息。 下面 让 我 
们 看 看 query_edd 方法 的 实现 。 


首先 ， 代 码 检查 内 核 命 令 行 参数 是 否 设置 了 edd 选项 ， 如 果 edd 选 项 设置 成 
off ， query_edd 不 做 任何 操作 ， 直 接 返 回 


如 果 EDD 被 激活 了 ， query_edd 遍历 所 有 BIOS 支 持 的 硬盘 ， 并 获取 相应 硬盘 的 EDD 信 息 : 


for (devno = 0x80; devno < Ox80+EDD_MBR_SIG MAX; devno++) { 
if (!get_edd_info(devno, &ei) && boot_params.eddbuf_entries < EDDMAXNR) { 
memcpy(edp, &ei, sizeof ei); 
edp++; 
boot_params.eddbuf_entries++; 


在 代码 中 oxso 是 第 一 块 硬盘 ， EDD_MBR_SIG_MAX 是 一 个 宏 ， 值 为 16。 代码 把 获得 的 信息 放 
入 数组 edd info 中 。 get_edd_info 方法 通过 调用 ox13 中 断 调用 《设置 ah = gx41 ) 来 检查 
EDD 是 否 被 硬盘 支持 。 如 果 EDD 被 支持 ， 代 码 将 再 次 调用 oxis 中 断 ， 在 这 次 调用 中 ah = 

gx48 ， 并 且 si 指向 一 个 数据 缓冲 区 地 址 。 中 断 调用 之 后 ，EDD 信 息 将 被 保存 到 si 指向 

的 缓冲 区 地 址 。 


结束 语 


本 章 到 此 就 结束 了 ， 在 下 一 章 我 们 将 讲解 显示 模式 设置 ， 以 及 在 进入 保护 模式 之 前 的 其 他 准 
备 工 作 ， 在 下 一 章 的 最 后 我 们 将 成 功 进 入 保护 模式 。 


如 果 你 有 任何 的 问题 或 者 建议 ， 你 可 以 留言 ， 也 可 以 直接 发 消息 给 我 twitter. 


如 果 你 发 现 文中 描述 有 任何 问题 ， 请 提交 一 个 PR 到 linux-insides-zh ° 


相关 链接 


e Protected mode 


在 内 核 安装 代码 的 第 一 步 


Protected mode 

Long mode 

Nice explanation of CPU Modes with code 

How to Use Expand Down Segments on Intel 386 and Later CPUs 
earlyprintk documentation 

Kernel Parameters 

Serial console 

Intel SpeedStep 

APM 

EDD specification 

TLDP documentation for Linux Boot Process (old) 
Previous Part 

BIOS Interrupt 
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内 核 启动 过 程 ， 第 三 部 分 


显示 模式 初始 化 和 进入 保护 模式 


一 章 是 内 核 启动 过 程 的 第 三 部 分 ， 在 前 一 章 中 ， 我 们 的 内 核 启 动 过 程 之 旅 停 在 了 对 
set_video 函数 的 调用 (这 个 函数 定义 在 main.c) 。 在 这 一 章 中 ， 我 们 将 接着 上 一 章 继续 我 
们 的 内 核 启动 之 旅 。 在 这 一 章 你 将 读 到 下 面 的 内 容 : 


e 显示 模式 的 初始 化 ， 
© 在 进入 保护 模式 之 前 的 准备 工作 ， 
© 正式 进入 保护 模式 


注意 如 果 你 对 保护 模式 一 无 所 知 ， 你 可 以 查看 阐 一 草 的 相关 内 容 。 另 外 ， 你 也 可 以 查看 下 面 
这 些 链 接 以 了 解 更 多 关于 保护 模式 的 内 容 。 


就 像 我 们 前 面 所 说 的 ， 我 们 将 从 set_video 函数 开始 我 们 这 章 的 内 容 ， 你 可 以 在 
arch/x86/boot/video.c 找到 这 个 函数 的 定义 。 这 个 函数 首先 从 boot_params.hdr 数据 结构 获 
取 显 示 模 式 设置 : 


u16 mode = boot_params.hdr.vid_mode; 
至 于 boot_params .hdr 数据 结构 中 的 内 容 ， 是 通过 copy_boot_params 函数 实现 的 (关于 这 


个 函数 的 实现 细节 请 查看 上 一 章 的 内 容 ) ” boot_params.hdr 中 的 vid_mode 是 引导 程序 必 
须 填 入 的 字段 。 你 可 以 在 kernel boot protocol 文档 中 找到 关于 vid mode 的 详细 信息 : 


offset Proto Name Meaning 
/Size 
01FA/2 ALL vid_mode Video mode control 


而 在 linux kernel boot protocol 文档 中 定义 了 如 何 通过 命令 行 参数 的 方式 为 vid_mode F 
段 传 入 相应 的 值 : 


**** SPECIAL COMMAND LINE OPTIONS 

vga=<mode> 
<mode> here is either an integer (in C notation, either 
decimal, octal, or hexadecimal) or one of the strings 
"normal" (meaning OXxFFFF), "ext" (meaning OxFFFE) or "ask" 
(meaning OxFFFD). This value should be entered into the 
vid_mode field, as it is used by the kernel before the command 
line is parsed. 


根据 上 面 的 描述 ， 我 们 可 以 通过 将 vga 选项 写 或 者 写 到 引导 程序 的 配置 文件 ， 从 而 


让 内 核 命令 行 得 到 相应 的 显示 村 evens 个 选项 可 以 接受 不 同类 型 的 值 来 表示 相同 的 
意思 。 比 如 你 可 以 传 入 OXFFFD 或 者 ask， 这 2 个 值 都 表示 需要 显示 一 个 菜单 让 用 户 选 择 想 要 


的 显示 模式 。 下 面 的 链接 就 给 出 了 这 个 菜单 : 


QEMU 
SeaBIOS (version 1.7.5-20140531_171129-lamiak) 


iPXE Chttp://ipxe.org) 00:03.0 C980 PCIZ.10 PnP PMM+3FFIOA40+3FEFOA40 C980 


Booting from ROM... 
early console in setup code 
Press <ENTER> to see video modes available, <SPACE> to continue, or wait 30 sec 
Mode: Resolution: Type: 
80x25 UGA 
80x50 UGA 
80x43 UGA 
80x28 UGA 
80x30 UGA 
80x34 UGA 
80x60 UGA 
40x25 VESA 
40x25 VESA 
80x25 VESA 
80x25 VESA 
80x25 VESA 
nter a video mode or “scan” to scan for additional modes: 





ae — 有 要 进入 的 显示 模式 。 不 过 在 我 们 进一步 了 解 显示 模式 的 设置 
zZ 


内 核 数 据 类 型 


在 前 面 的 章节 中 ， 我 们 已 经 接触 到 了 一 个 类 似 于 ute 的 内 核 数 据 类 型 。 下 面 列 出 了 更 多 内 核 
支持 的 数据 类 型 : 


Type char short int long u8 u16 U32 u64 
Size 1 2 4 8 1 2 4 8 


如 果 你 尝试 阅读 内 核 代码 ， 最 好 能 够 牢记 这 些 数据 类 型 。 


堆 操 作 API 


在 set_video 函数 将 vid mod 的 值 设 置 完 成 之 后 ， 将 调用 RESET_HEAP 宏 将 HEAP 头 指向 
_end 符号 。 RESET_HEAP 宏 定 义 在 


#define RESET_HEAP() ((void *)( HEAP = _end )) 


如 果 你 阅读 过 第 二 部 分 ， 你 应 该 还 记得 在 第 二 部 分 中 ， 我 们 通过 init_heap 函数 完成 了 
HEAP 的 初始 化 。 在 boot.h 中 定义 了 一 系列 的 方法 来 操作 被 初始 化 之 后 的 HEAP。 这 些 操 
作 和 包括 : 


#define RESET_HEAP() ((void *)( HEAP = _end )) 


就 像 我 们 在 前 面 看 到 的 ， 这 个 宏 只 是 简单 的 将 HEAP 头 设置 到 end 标号 。 在 上 一 章 中 我 们 
已 经 说 明了 _end 标号 ， 在 boot.h 中 通过 extern char end[]; 来 引用 (从 这 里 可 以 看 

出 ， 在 内 核 初始 化 的 时 候 堆 和 栈 是 共享 内 存 空间 的 ， 详 细 的 信息 可 以 查看 第 一 章 的 堆栈 初始 
化 和 第 二 章 的 堆 初始 化 ) 


下 面 一 个 是 GET_HEAP 宏 : 


#define GET_HEAP(type, n) \ 
((type *)__get_heap(sizeof(type),__alignof__(type),(n))) 


可 以 看 出 这 个 宏 调用 了 _ get_heap 函数 来 进行 内 存 的 分 配 ° _ get heap 需要 下 面 3 个 参数 
来 进行 内 存 分 配 操 作 : 
o 菜 个 数据 类 型 所 占用 的 字 节 数 
e _ alignof (type) 返回 对 于 请 求 的 数据 类 型 需要 怎样 的 对 齐 方 式 ( 根据 我 的 了 解 这 个 是 
gcc 提供 的 一 个 功能 ) 
© n 需要 分 配 多 少 个 对 应 数据 类 型 的 对 象 


下 面 是 _ get_heap 函数 的 实现 : 


static inline char *__get_heap(size_t s, size_t a, size_t n) 


{ 
char *tmp; 
HEAP = (char *)(((size_t)HEAP+(a-1)) & ~(a-1)); 
tmp = HEAP; 
HEAP += s*n; 
return tmp; 
} 


现在 让 我 们 来 了 解 这 个 函数 是 如 何 工作 的 。 这 个 函数 首先 根据 对 齐 方 式 要 求 (参数 a) A 
整 HEAP 的 值 ， 然 后 将 HEAP 值 赋值 给 一 个 临时 变量 tmp 。 接 下 来 根据 需要 分 配 的 对 象 的 
个 数 (参数 n ) ， 预 留 出 所 需要 的 内 存 ， 然 后 将 tmp 返回 给 调用 端 。 


最 后 一 个 关于 HEAP 的 操作 是 : 


static inline bool heap_free(size_t n) 


{ 
return (int)(heap_end - HEAP) >= (int)n; 


} 


这 个 函数 简单 做 了 一 个 减法 heap_end - HEAP ， 如 果 相 减 的 结果 大 于 请 求 的 内 存 ， 那 么 就 返回 
> BH MRR o 


我 们 已 经 看 到 了 所 有 可 以 对 HEAP 进行 操作 ， 下 面 让 我 们 继续 显示 模式 设置 过 程 。 


设置 显示 模式 


在 我 们 分 析 了 内 核 数 据 类 型 以 及 和 HEAP 相关 的 操作 之 后 ， 让 我 们 回来 继续 分 析 显 示 模 式 的 
初始 化 。 在 RESET_HEAP( ) 函数 被 调用 之 后 ， set_video 函数 接着 调用 store_mode_params 
函数 将 对 应 显示 模式 的 相关 参数 写 入 boot_params.screen_info 字段 。 这 个 字段 的 结构 定义 可 
以 在 include/uapi/linux/screen_info.h 中 找到 。 


store_mode_params 函数 将 调用 store_cursor_position 函数 将 当前 屏幕 上 光标 的 位 置 保存 起 
来 。 下 面 让 我 们 来 看 store cursor_poistion 函数 是 如 何 实现 的 。 


首先 函数 初始 化 一 个 类 型 为 biosregs 的 变量 ， 将 其 中 的 AH 寄存 器 内 容 设 置 成 0x3 ， 然 后 
调用 ox10 BIOS 中 断 。 当 中 断 调用 返回 之 后 ，DL 和 DH 寄存 器 分 别 包 含 了 当前 光标 的 行 
和 列 信 息 。 接 着 ， 这 2 个 信息 将 被 保存 到 boot_params.screen_info 字段 的 orig_x 和 
orig_y 字段 。 


Za > pe 


在 store_cursor_position 函数 执行 完毕 之 后 ， store_mode_params 函数 将 调用 
store_video_mode 函数 将 当前 使 用 的 显示 模式 保存 到 


boot_params.screen_info.orig_video_mode ° 


接 下 来 store_mode_params 函数 将 根据 当前 显示 模式 的 设 定 ， 给 video_segment 变量 设置 正 
确 的 值 (实际 上 就 是 设置 显示 内 存 的 起 始 地 址 ) o Æ BIOS 将 控制 权 转 移 到 引导 扇 区 的 时 
候 ， 显 示 内 存 地 址 和 显示 模式 的 对 应 关系 如 下 表 所 示 : 


0xB000 : 0x0000 32 Kb Monochrome Text Video Memory 
0xB800 : 0x0000 32 Kb Color Text Video Memory 


根据 上 表 ， 如 果 当 前 显示 模式 是 MDA, HGC 或 者 单 色 VGA 模式， 那么 video_sgement 的 值 
将 被 设置 成 oxpooo ; 如 果 当 前 显示 模式 是 彩色 模式 ， 那 么 video_segment 的 值 将 被 设置 成 
OxB800 ° 在 这 之 后 ” store_mode_params 函数 将 保存 字体 大 小 信 息 到 


boot_params.screen_info.orig_video_points 


// 保 存 字体 大 小 信息 

set_fs(0); 

font_size = rdfs16(0x485); 
boot_params.screen_info.orig_video_points = font_size; 


这 段 代 码 首 先 调用 set_fs BH (在 booth 中 定义 了 许多 类 似 的 函数 进行 寄存 器 操作 ) 将 数 
Z o XA Fs 寄存 器 。 接 着 从 内 存 地 址 gx485 处 获取 字体 大 小 信息 并 保存 到 


boot_params.screen_info.orig_video_points ° 


x = rdfsi16(0x44a); 
(adapter == ADAPTER_CGA) ? 25 : rdfs8(0x484)+1; 


< 
ll 


接 下 来 代码 将 从 地 址 gx44a 处 获得 屏幕 列 信息 ， 从 地 址 gx484 处 获得 屏幕 行 信息 ， 并 将 它 
们 保存 到 boot_params.screen_info.orig_video_cols 


boot_params.screen_info.orig_video_lines ° 到 这 ” store_mode_params 的 执行 就 结束 了 i 


接 下 来 set video 函数 将 调用 save screen 函数 将 当前 屏幕 上 的 所 有 信息 保存 到 HEAP 
中 。 这 个 男 数 首先 闭 得 当前 屏 划 的 所 有 信息 ( 包括 屏幕 大 小 SHEREE MELU 
信息 ) ， 并 且 保 存 到 saved screen 结构 体 中 。 这 个 结构 体 的 定义 如 下 所 示 : 


static struct saved_screen { 
int x, y; 
int curx, cury; 
U16 *data; 

} saved; 


接 下 来 函数 将 检查 HEAP 中 是 否 有 足够 的 空间 保存 这 个 结构 体 的 数据 : 


if (!heap_free(saved.x*saved.y*sizeof(u16)+512) ) 
return; 


如 果 HEAP 有 足够 的 空间 ， 代 码 将 在 HEAP 中 分 配 相应 的 空间 并 且 将 saved_screen 保存 到 
HEAP 。 


接 下 来 set_video 函数 将 调用 probe_cards(o) (这 个 函数 定义 在 arch/x86/boot/Video- 
mode.c) 。 这 个 函数 简单 遍历 所 有 的 显卡 ， 并 通过 调用 驱动 程序 设置 显卡 所 支持 的 显示 模 
A: 


for (card = video_cards; card < video_cards_end; card++) { 
if (card->unsafe == unsafe) { 
if (card->probe) 
card->nmodes = card->probe(); 
else 


card->nmodes 0; 


如 果 你 仔细 看 上 面 的 代码 ， 你 会 发 现 video cards 这 个 变量 并 没有 被 声明 ， 那 么 程序 怎么 能 
够 正常 编译 执行 呢 ? 实际 上 很 简单 ， 它 指向 了 一 个 在 arch/x86/boot/setup.ld 中 定义 的 叫做 
.Videocards 的 内 存 段 : 


.videocards a 
video_cards = .; 
*(.videocards) 
video_cards_end = .; 


那么 这 段 内 存 里 面 存放 的 数据 是 什么 呢 ， 下 面 我 们 就 来 详细 分 析 。 在 内 核 初 始 化 代码 中 ， 对 
于 每 个 支持 的 显示 模式 都 是 使 用 下 面 的 代码 进行 定义 的 : 


static _ videocard video_vga = { 


.card_name = "VGA", 
. probe = vga_probe, 
.set_mode = vga_set_mode, 


}; 


_videocard 是 一 个 宏 定义 ， 如 下 所 示 : 


#define _ videocard struct card_info _ attribute_ ((used,section(".videocards"))) 


因此 — videocard 是 一 个 card_info 结构 ， 这 个 结构 定义 如 下 : 


struct card_info { 
const char *card_name; 
int (*set_mode)(struct mode_info *mode); 
int (*probe)(void); 
struct mode_info *modes; 
int nmodes; 
int unsafe; 
u16 xmode_first; 
u16 xmode_n; 


}; 


在 .videocards 内 存 段 实际 上 存放 的 就 是 所 有 被 内 核 初始 化 代码 定义 的 card_info 结构 (可 
以 看 成 是 一 个 数组 ) ， 所 以 probe_cards 函数 可 以 使 用 video_cards ， 通 过 循环 遍历 所 有 的 


card_info ° 


在 probe_cards 执行 完成 之 后 ， 我 们 终于 进入 set_video 函数 的 主 循环 了 。 在 这 个 循环 中 ， 
如 果 vid_mode=ask ， 那 么 将 显示 一 个 菜单 让 用 户 选择 想 要 的 显示 模式 ， 然 后 代码 将 根据 用 户 
的 选择 或 者 vid_mod 的 值 ， 通 过 调用 set_mode 函数 来 设置 正确 的 显示 模式 。 如 果 设 置 成 

功 ， 循 环 结束 ， 否 则 显示 菜单 让 用 户 选择 显示 模式 ， 继 续 进 行 设置 显示 模式 的 尝试 。 


for (;;) { 
If (mode == ASK_VGA) 
mode = mode_menu(); 


if (!set_mode(mode) ) 
break; 


printf("Undefined video mode number: %x\n", mode); 
mode = ASK_VGA; 


你 可 以 在 video-mode.c 中 找到 set_mode 欧 数 的 定义 。 这 个 函数 只 接受 一 个 参数 ， 这 个 参数 
是 对 应 的 显示 模式 的 数字 表示 (这 个 数字 来 自 于 显示 模式 选择 菜单 ， 或 者 从 内 核 命令 行 参 数 


获得 ) 


IRIT 


o 


set_mode 函数 首先 检查 传 入 的 mode 参数 ， 然 后 调用 raw set_mode 函数 。 而 后 者 将 遍历 内 
核 知道 的 所 有 card_info 信息 ， 如 果 发 现 某 张 显 卡 支持 传 入 的 模式 ， 这 调用 card_info 结 
构 中 保存 的 set_mode 函数 地 址 进行 显卡 显示 模式 的 设置 ° VA video_vga 这 个 card_info 
结构 来 说 保存 在 其 中 的 set_mode 函数 就 指向 了 vga_set_mode yee o Fay RAG he 
vga_set_mode 函数 的 实现 ， 这 个 函数 根据 输入 的 vga 显示 模式 ， 调 用 不 同 的 函数 完成 显示 模 
式 的 设置 : 


在 上 面 的 代码 中 ， 每 个 
置 。 

在 显卡 的 显示 模 
boot_params.hdr.vid_mode 

接 下 来 set_video 
(Extended Display Identification Data) 4 


用 do_restore 


到 这 


在 切换 到 保护 模 


static int vga 


{ 


文 里 为 止 ， 显 示 模 


vga_set_basic_mode(); 


force x = mode->x; 
force_y = mode->y; 


switch (mode->mode) { 

case VIDEO_80x25: 
break; 

case VIDEO_8POINT: 
vga_set_8font(); 
break; 

case VIDEO_80x43: 
vga_set_80x43(); 
break; 

case VIDEO_80x28: 
vga_set_14font(); 
break; 

case VIDEO_80x30: 
vga_set_80x30(); 
break; 

case VIDEO_80x34: 
vga_set_80x34(); 
break; 

case VIDEO_80x60: 
vga_set_80x60(); 
break; 


} 


return o; 


set_mode(struct mode_info 


vga_set*** 


式 被 正确 设置 之 后 


o 


HAAA vesa_store_edid 


*mode) 


只 是 简单 调用 gx16 BIOS 中 断 来 进行 


这 个 最 终 的 显示 模式 被 写 回 


模式 的 设置 完成 ， 接 下 来 我 们 可 以 切换 到 保护 模式 了 。 


式 之 前 的 最 后 的 准备 工作 


函数 ， 这 个 函数 只 是 简单 的 将 EDID 
写 入 内 存 ， 以 便于 内 核 访 问 。 最 后 ， 
函数 将 前 面 保 存 的 当前 屏幕 信息 还 原 到 屏幕 上 。 


未 模 式 的 设 


显示 


set_video 将 调 


在 进入 保护 模式 之 前 的 最 后 一 个 函数 调用 发 生 在 main.c 中 的 go_to_protected_mode 了 有 函数， 就 
像 这 个 函数 的 注释 说 的 ， 这 个 函数 将 进行 最 后 的 准备 工作 然后 进入 保护 模式 ， 下 面 就 让 我 们 
来 具体 看 看 最 后 的 准备 工作 是 什么 ， 以 及 系统 是 如 何 切换 到 保护 模式 的 。 


go_to_protected_mode 函数 本 身 定义 在 arch/x86/boot/pm.c° 这 个 函数 调用 了 一 些 其 他 的 函 
数 进行 最 后 的 准备 工作 ， 下 面 就 让 我 们 来 具体 看 看 这 些 函 数 。 


go_to_protected_mode 函数 首先 调用 的 是 realmode_switch_hook 42k > 后 者 如 果 发 现 
realmode_switch hook， 那么 将 调用 它 并 禁止 NMI 中 断 ， 反 之 将 直接 禁止 NMI 中 断 。 只 有 
当 bootloader 运行 在 宿主 环境 下 (比如 在 DOS 下 运行 ) > hook 才 会 被 使 用 。 你 可 以 在 
boot protocol (see ADVANCED BOOT LOADER HOOKS) 中 详细 了 解 hook 函数 的 信息 。 


ye 
* Invoke the realmode switch hook if present; otherwise 
* disable all interrupts. 


z 
static void realmode_switch_hook(void) 
{ 
if (boot_params.hdr.realmode_swtch) { 
asm volatile("lcallw *%0" 
: : "m" (boot_params.hdr.realmode_swtch) 
: "eax", “ebx", "ecx", "edx" ); 
} else { 
asm volatile("cli"); 
outb(0x80, 0x70); /* Disable NMI */ 
io_delay(); 
} 
} 


realmode_switch 指向 了 一 个 16 位 实 模式 代码 地 址 〈 远 跳 转 指针 ) ， 这 个 16 位 代码 将 禁止 

NMI 中 断 。 所 以 在 上 述 代 码 中 ， 如 果 realmode_swtch hook 存在 ， 代 码 是 用 了 1lcallw 指令 
进行 远 函 数 调 用 。 在 我 的 环境 中 ， 因 为 不 存在 这 个 hook ， 所 以 代码 是 直接 进入 else 部 分 
进行 了 NMI 49 Sak : 


asm volatile("cli"); 
outb(0x80, 0x70); /* Disable NMI */ 
io_delay(); 


上 面 的 代码 首先 调用 cli 汇编 指令 清除 了 中 断 标志 IF ， 这 条 指令 执行 之 后 ， 外 部 中 断 就 被 
禁止 了 ， 紧 接着 的 下 一 行 代码 就 禁止 了 NMI 中 断 。 


这 里 简单 介绍 一 下 中 断 。 中 断 是 由 硬件 或 者 软件 产生 的 ， 当 中 断 产生 的 时 候 ，CPU 将 得 到 通 
知 。 这 个 时 候 ，CPU 将 停止 当前 指令 的 执行 ， 保 存 当 前 代码 的 环境 ， 然 后 将 控制 权 移 交 到 中 
断 处 理 程序 。 当 中 断 处理 程 序 完 成 之 后 ， 将 恢复 中 断 之 前 的 运行 环境 ， 从 而 被 中 断 的 代码 将 


继续 运行 。NMI 中 断 是 一 类 特殊 的 中 断 ， 往 往 预 示 着 系统 发 生 了 不 可 恢复 的 错误 ， 所 以 在 正 
常 运行 的 操作 系统 中 ，NMI 中 断 是 不 会 被 禁止 的 ， 但 是 在 进入 保护 模式 之 前 ， 由 于 特殊 需 
求 ， 代 码 禁止 了 这 类 中 断 。 我 们 将 在 后 续 的 章节 中 对 中 断 做 更 多 的 介绍 ， 这 里 就 不 展开 了 。 


现在 让 我 们 回 到 上 面 的 代码 ， 在 NMI 中 断 被 禁止 之 后 〈 通 过 写 oxo 进 CMOS 地 址 寄存 器 
0x70 ) ， 函 数 接着 调用 了 io delay 函数 进行 了 短暂 的 延 时 以 等 待 |/O 操作 完成 。 下 面 就 是 
io_delay 有 函数 的 实现 : 


static inline void io_delay(void) 


{ 
const U16 DELAY_PORT = 0x80; 
asm volatile("outb %%al,%0" : : "dN" (DELAY_PORT)); 


对 WO 端口 oxso 写 入 任何 的 字 节 都 将 得 到 1 ms 的 延 时 。 在 上 面 的 代码 中 ， 代 码 将 al F 
存 器 中 的 值 写 到 了 这 个 端口 。 在 这 个 io delay 调用 完成 之 后 ， realmode_switch_hook 函数 
就 完成 了 所 有 工作 ， 下 面 让 我 们 进入 下 一 个 函数 。 


下 一 个 函数 调用 是 enable_azo ， 这 个 函数 使 能 A20 line， 你 可 以 在 arch/x86/boot/a20.c 找到 
这 个 函数 的 定义 ， 这 个 函数 会 尝试 使 用 不 同 的 方式 来 使 能 A20 地 址 线 。 首 先 这 个 函数 将 调用 
a20_test_short (该 函数 将 调用 a20 test HA) 来 检测 A20 地 址 线 是 否 已 经 被 激活 了 : 


static int a20_test(int loops) 
{ 

int ok = 0; 

int saved, ctr; 


set_fs(0x0000); 
set_gs(Oxffff); 


saved = ctr = rdfs32(A20_TEST_ADDR) ; 


while (loops--) { 
wrfs32(++ctr, A20_TEST_ADDR); 
io_delay(); /* Serialize and make delay constant */ 
ok = rdgs32(A20_TEST_ADDR+0xi0) ^ ctr; 
if (ok) 
break; 


} 


wrfs32(saved, A20_TEST_ADDR); 
return ok; 


这 个 函数 首先 将 ox6008 MA Fs 寄存 器 ， 将 gxffff HA GS 寄存 器 。 然 后 通过 rdfs32 
函数 调用 ， 将 A26 TEST ADDR 内 存 地 址 的 内 容 放 入 saved 和 ctr 变量 。 


接 下 来 我 们 使 用 wrfs32 函数 将 更 新 过 的 ctr 的 值 写 入 fs:gs ， 接 着 延 时 IMs’ REM 
GS:A20_TEST_ADDR+0x10 读 取 内 容 ， 如 果 该 地 址 内 容 不 为 0， 那 么 A20 已 经 被 激活 。 如 果 A20 
没有 被 激活 ， 代 码 将 尝试 使 用 多 种 方法 进行 A20 地 址 激活 。 其 中 的 一 种 方法 就 是 调用 BIOS 
gx15 中 断 激活 A20 地 址 线 。 


如 果 enabled_a20 函数 调用 失败 ， 显 示 一 个 错误 消息 并 且 调 用 die 函数 结束 操作 系统 运 
行 。die 函数 定义 在 arch/x86/boot/header.S: 


die 
hit 
jmp die 
.Size die, die 


A20 地 址 线 被 激活 之 后 ， reset_coprocessor 函数 被 调用 : 


outb(0, Oxf0); 
outb(0, Oxf1); 


这 个 函数 非常 简单 ， 通 过 将 6 写 入 WO 端口 gxf@ 和 oxfa 以 复位 数字 协 处 理 器 。 


接 下 来 mask_all_interrupts 函数 将 被 调用 : 


outb(Oxff, Oxa1); /* Mask all interrupts on the secondary PIC */ 
outb(Oxfb, 0x21); /* Mask all but cascade on the primary PIC */ 


这 个 函数 调用 屏蔽 了 从 中 断 控 制 器 ( 注 : 中 断 控制 器 的 原文 是 Programmable Interrupt 
Controller) 的 所 有 中 断 ， 和 主 中 断 控制 器 上 除 IRQ2 以 外 的 所 有 中 断 (IRQ2 是 主 中 断 控制 器 上 
的 级 联 中 断 ， 所 有 从 中 断 控 制 器 的 中 断 将 通过 这 个 级 联 中 断 报告 给 CPU ) 。 


到 这 里 位 置 ， 我 们 就 完成 了 所 有 的 准备 工作 ， 下 面 我们 就 将 正式 开始 从 实 模式 转换 到 保护 模 
式 o 


设置 中 断 描述 符 表 


现在 内 核 将 调用 setup_idt 方法 来 设置 中 断 描述 符 表 ( IDT ) 


static void setup_idt(void) 

{ 
static const struct gdt_ptr null_idt = {0, 0}; 
asm volatile("lidtl %0" : : "m" (null_idt)); 


上 面 的 代码 使 用 1idtl 指令 将 null_idt 所 指向 的 中 断 描述 符 表 引 入 寄存 器 IDT。 由 于 
null_idt 没有 设 定 中 断 描述 符 表 的 长 度 〈 长 度 为 0 ) ， 所 以 这 段 指令 执行 之 后 ， 实 际 上 没有 
任何 中 断 调 用 被 设置 成 功 AT ae ab) > 在 后 面 的 章节 中 我 们 将 看 到 正确 的 设 
置 。 null_idt 是 一 个 gdt_ptr 结构 的 数据 ， 这 个 结构 的 定义 如 下 所 示 : 


struct gdt_ptr { 
U16 len; 
u32 ptr; 
} __attribute__((packed)); 


在 上 面 的 定义 中 ， 我 们 可 以 看 到 上 面 这 个 结构 包含 一 个 16 bit 的 长 度 字 段 ， 和 一 个 32 bit 的 
指针 字段 。 attribute ((packed)) ee 告 构 就 只 包含 48 bit 信息 (没有 字 节 对 齐 优 
化 ) 。 在 下 面 一 节 中 ， 我 们 将 看 到 相同 的 结构 将 被 导入 corr 寄存 器 (如果 你 还 记得 上 一 章 
的 内 容 ， 应 该 记得 GDTR 寄存 器 是 48 bit 长 度 的 ) 。 


没 置 全 局 描述 符 表 


在 设置 完 中 断 描述 符 表 之 后 ， 我 们 将 使 用 setu git 函数 来 设置 全 局 描述 符 表 (关于 全 局 描 
述 符 表 2 大 家 可 以 参考 上 一 章 o 。 在 setup_gdt wy YP ? boot_gdt 数组 定义 了 
需要 引入 GDTR 寄存 器 的 段 描述 符 信 息 


//GDT_ENTRY_BOOT_CS © X#http://l1xr.free-electrons.com/source/arch/x86/include/asm/ 
segment.h#L19 = 2 
static const u64 boot_gdt[] __attribute__((aligned(i6))) = { 
[GDT_ENTRY_BOOT_CS] = GDT_ENTRY(0xcO09b, 0, Oxfffff), 
[GDT_ENTRY_BOOT_DS] = GDT_ENTRY(0xc093, 0, Oxfffff), 
[GDT_ENTRY_BOOT_TSS] = GDT_ENTRY(0x0089, 4096, 103), 


J}; 


在 上 面 的 boot_gdt 数组 中 ， 我 们 定义 了 代码 ， 数 据 和 TSS 段 (Task State Segment, 任务 状 
态 段 ) 的 段 描 述 符 ， 因 为 我 们 并 没有 设置 任何 的 中 断 调用 (记得 上 面 说 的 null idt 吗 ? 了 )， 
所 以 TSS 段 并 不 会 被 使 用 到 。TSS 段 存在 的 唯一 目的 就 是 让 Intel 处 理 器 能 够 正确 进入 保护 
ER. TERNYATA T M 这 个 数组 ， 首 先 ， 这 个 数组 被 
_attribute_((aligned(16))) 修饰 ， 这 就 意味 着 这 个 数组 将 以 16 字 节 为 单位 对 齐 。 让 我 们 
通过 下 面 的 例子 来 了 解 一 下 什么 叫 16 字 节 对 齐 


#include <stdio.h> 


struct aligned { 

int a; 
}__attribute__((aligned(16))); 
struct nonaligned { 

ant by 


}; 


int main(void) 


{ 
struct aligned a; 
struct nonaligned na; 
printf("Not aligned - %zu \n", sizeof(na)); 
printf("Aligned - %zu \n", sizeof(a)); 
return 0; 

} 


上 面 的 代码 可 以 看 出 ， 一 旦 指定 了 16 字 节 对 齐 ， 即 使 结构 中 只 有 一 个 int 类 型 的 字段 ， 整 
个 结构 也 将 占用 16 个 字 节 : 


$ gcc test.c -o test && test 
Not aligned - 4 
Aligned - 16 


因为 在 boot_gdt 的 定义 中 ， GDT_ENTRY_BOOT_CS = 2 ， 所 以 在 数组 中 有 2 个 空 项 ， 第 一 项 是 
一 个 空 的 描述 符 ， 第 二 项 在 代码 中 没有 使 用 。 在 没有 align 16 之 前 ， 整 个 结构 占用 了 
(8*5=40) 个 字 节 ， 加 了 align 16 之 后 ， 结构 就 占用 了 48 PY 。 


上 面 代码 中 出 现 的 GDT_ENTRY 是 一 个 宏 定义 ， 这 个 宏 接 受 3 个 参数 (标志 ， 基 地 址 ， 段 长 
FE) 来 产生 段 描述 符 结构 。 让 我 们 来 具体 分 析 上 面 数 组 中 的 代码 段 描 述 符 ( 
GDT_ENTRY BOOT CS ) 来 看 看 这 个 宏 是 如 何 工 作 的 ， 对 于 这 个 段 ， GDT_ENTRY 接受 了 下 面 3 
个 参数 : 


e 基地 址 -0 
e 段 长 度 - Oxfffff 
e 标志 - 0xc09b 


上 面 这 些 数 字 表明 ， 这 个 段 的 基地 址 是 0 ， 段 长 度 是 gxfffff (1MB) ;而 标志 字段 展开 
之 后 是 下 面 的 二 进 制 数据 : 


1100 0000 1001 1011 


这 些 二 进 制 数据 的 具体 含义 如 下 : 


1-(G) 这 里 为 1， 表示 上 段 的 实际 长 度 是 gxfffff * 4kb = 46B 
© 1-(D) 表示 这 个 段 是 一 个 32 位 段 
0 - (L) 这 个 代码 段 没有 运行 在 long mode 
e 0 -(AVL)Linux 没有 使 用 
e 0000 - 段 长 度 的 4 个 位 
。 1-(P) 段 已 经 位 于 内 存 中 
。 00 - (DPL) - 段 优先 级 为 0 
© 1-(S) 说 明 这 个 段 是 一 个 代码 或 者 数据 段 
© 101 - 段 类 型 为 可 执行 /可 读 
。1 - 段 可 访问 


关于 段 描述 符 的 更 详细 的 信息 你 可 以 从 上 一 章 中 获得 上 一 竟 ， 你 也 可 以 阅读 Intel® 64 and 
IA-32 Architectures Software Developers Manuals 3A 获 取 全 部 信息 。 


在 定义 了 数组 之 后 ， 代 码 将 获取 GDT 的 长 度 : 
gdt.len = sizeof(boot_gdt)-1; 

接 下 来 是 将 GDT 的 地 址 放 入 gdt.ptr 中 : 
gdt.ptr = (u32)&boot_gdt + (ds() << 4); 


这 里 的 地 址 计算 很 简单 ， 因 为 我 们 还 在 实 模式 ， 所 以 就 是 ( ds << 4+ 数组 起 始 地 址 ) © 


最 后 通过 执行 lgdt1l 指令 将 GDT 信息 写 入 GDTR 寄存 器 : 


asm volatile("lgdtl %0" : : "m" (gdt)); 


切换 进入 保护 模式 


go_to_protected_mode HAE ZA IDT, GDT 初始 化 ， 并 禁止 了 NMI 中 断 之 后 ， 将 调用 
protected_mode_jump 函数 完成 从 实 模式 到 保护 模式 的 跳 转 : 


protected_mode_jump(boot_params.hdr.code32_start, (u32)&boot_params + (ds() << 4)); 


protected_mode_jump ÁA Æ LÆ arch/x86/boot/pmjump.S， 它 接受 下 面 2 个 参数 : 


o 保护 模式 代码 的 入 口 
e poot_params 结构 的 地 址 


第 一 个 参数 保存 在 eax 寄存 器 ， 而 第 二 个 参数 保存 在 edx 寄存 器 。 


代码 首先 在 boot_params 地 址 放 入 esi 寄存 器 ， 然 后 将 cs 寄存 器 内 容 放 入 bx 寄存 器 ， 
接着 执行 bx << 4 + 标号 为 2 的 代码 的 地 址 ， 这 样 一 来 bx 寄存 器 就 包含 了 标号 为 2 的 代码 的 地 
址 。 接 下 来 代码 将 把 数据 段 索 引 放 入 cx 寄存 器 ， 将 TSS 段 索 引 放 入 di 寄存 器 : 


movw $ BOOT_DS, %cx 
movw $ BOOT_TSS, %di 


就 像 前 面 我 们 看 到 的 GDT_ENTRY_BooT_ Cs 的 值 为 2， 每 个 段 描述 符 都 是 8 字 节 ， 所 以 cx F 
存 器 的 值 将 是 2*8 = 16 ， di 寄存 器 的 值 将 是 4*8 =32 © 


接 下 来 ， 我 们 通过 设置 cro 寄存 器 相应 的 位 使 CPU 进入 保护 模式 : 


movl %crO, %edx 
orb $X86_CRO_PE, %d1 
movl %edx, %CrO 


在 进入 保护 模式 之 后 ， 通 过 一 个 长 跳 转 进入 32 位 代码 : 


.byte 0x66, Oxea 


2: . long in_pm32 
.word __BOOT_CS ;(GDT_ENTRY_BOOT_CS*8) = 16， 段 描述 符 表 索引 
这 段 代 码 中 


。 gx66 操作 符 前 级 允许 我 们 混合 执行 16 位 和 32 位 代码 
© oxea - 跳 转 指令 的 操作 符 

e in_pm32 跳 转 地 址 偏 移 

e Boor cs 代码 段 描述 符 索 引 


在 执行 了 这 个 跳 转 命令 之 后 ， 我 们 就 在 保护 模式 下 执行 代码 了 : 


.code32 
.section ".text32","ax" 


保护 模式 代码 的 第 一 步 就 是 重 置 所 有 的 段 寄存 器 (除了 cs FAR): 


GLOBAL (in_pm32) 


movl %ecx, %ds 
movl %ecx, %es 
movl %ecx, %fs 
movl %ecx, %gs 


movl %ecx, %SS 


还 记得 我 们 在 实 模式 代码 中 将 s soros (数据 段 描述 符 索 引 ) HAT cx 寄存 器 ， 所 以 
上 面 的 代码 设置 所 有 上段 寄 存 器 (除了 cs 寄存 器 ) 指向 数据 段 。 接 下 来 代码 将 所 有 的 通用 寄 
存 器 清 0 : 


xorl %ecx, %ECX 
xorl %edx, %edx 
xorl %ebx, %ebx 
xorl %ebp, %ebp 
xorl %edi, %edi 


最 后 使 用 长 跳 转 跳 入 正在 的 32 位 代码 (通过 参数 传 入 的 地 址 ) 


jmpl *%eax ;?jmpl cs:eax? 


到 这 里 ， 我 们 就 进入 了 保护 模式 开始 执行 代码 了 ， 下 一 章 我 们 将 分 析 这 上 段 32 位 代码 到 底 做 了 
些 什么 。 


这 章 到 这 里 就 结束 了 ， 在 下 一 章 中 我 们 将 具体 介绍 这 章 最 后 跳 转 到 的 32 位 代码 ， 并 且 了 解 系 
统 是 如 何 进入 long mode 的 。 


如 果 你 有 任何 的 问题 或 者 建议 ， 你 可 以 留言 ， 也 可 以 直接 发 消息 给 我 twitter. 


如 果 你 发 现 文中 描述 有 任何 问题 ， 请 提交 一 个 PR 到 linux-insides-zh ° 


链 援 
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内 核 引 导 过 程 .Part 4. 


切换 到 64 位 模式 


这 是 内 核 引导 过 程 的 第 四 部 分 ， 我 们 将 会 看 到 在 保护 模式 中 的 最 初 几 步 ， 比 如 确认 CPU 是 否 
支持 长 模式 ，SSE 和 分 页 以 及 页 表 的 初始 化 ， 在 这 部 分 的 最 后 我 们 还 将 讨论 如 何 切 换 到 长 模 
Ko 


注意 : 这 部 分 将 会 有 大 量 的 汇编 代码 ， 如 果 你 不 熟悉 汇编 ， 建 议 你 找 本 书 参 考 一 下 。 


在 前 一 章节 ， 我 们 停 在 了 跳 转 到 位 于 arch/x86/boot/pmjump.S 的 32 位 入 口 点 这 一 步 : 


jmpl *%eax 


回忆 一 下 ， eax 寄存 器 包含 了 32 位 入 口 点 的 地 址 。 我 们 可 以 在 x86 linux 内 核 引导 协议 中 
找到 相关 内 容 : 


When using bzImage, the protected-mode kernel was relocated to 0x100000 


当 使 用 bzImage 时 ， 保 护 模 式 下 的 内 核 被 重 定位 至 Ox100000 





让 我 们 检查 一 下 32 位 入 口 点 的 寄存 器 值 来 确保 这 是 对 的 : 


eax Ox100000 1048576 
ecx 0x0 0 

edx 0x0 0 

ebx 0x0 0 

esp Ox1ff5c Ox1ff5c 
ebp 0x0 0x0 

esi 0x14470 83056 

edi 0x0 0 

eip 0x100000 0x100000 
eflags 0x46 [ PF ZF ] 
cs 0x10 16 

SS 0x18 24 

ds 0x18 24 

es 0x18 24 

fs 0x18 24 


gs 0x18 24 


我 们 在 这 里 可 以 看 到 cs 寄存 器 包含 了 - oao (回忆 前 一 章节 ， 这 代表 了 全 局 描述 符 表 中 
的 第 二 个 索引 项 ) > eip 寄存 器 的 值 是 gxi66668 ， 并 且 包 括 代码 段 在 内 的 所 有 内 存 段 的 基 
地 址 都 为 0。 所 以 我 们 可 以 得 到 物理 地 址 : 0:0x100000 或 者 ox190000 ， 这 和 协议 规定 的 一 
样 。 现 在 让 我 们 从 32 位 入 口 点 开始 。 


32 位 入 口 点 
我 们 可 以 在 汇编 源码 arch/x86/boot/compressed/head_64.S 中 找到 32 位 入 口 点 的 定义 。 


— HEAD 
,Code32 
ENTRY(startup_32) 


ENDPROC(startup_32) 


首先 ， 为 什么 目录 名 叫做 被 压缩 的 (compressed) ?实际 上 bzimage 是 由 vmlinux + 头 文件 + 
内 核 启动 代 码 被 gzip 压缩 之 后 获得 的 。 我 们 在 前 几 个 章节 已 经 看 到 了 启动 内 核 的 代码 。 所 以 ， 
head_64.S 的 主要 目的 就 是 做 好 进入 长 模式 的 准备 之 后 进入 长 模式 ， 进 入 以 后 再 解压 内 核 。 
在 这 一 章节 ， 我 们 将 会 看 到 直到 内 核 解 压缩 之 前 的 所 有 步骤 。 


在 arch/x86/boot/compressed 目 录 下 有 两 个 文件 : 


e head 32.S 
e head 64.S 


但 是 ， 你 可 能 还 记得 我 们 这 本 书 只 和 x86_64 有关 ， 所 以 我 们 只 会 关注 head_ 64.S 3 在 我 们 
这 里 head 32.S 没有 被 用 到 。 让 我 们 看 一 下 arch/x86/boot/compressed/Makefile。 在 那里 我 
们 可 以 看 到 以 下 目标 : 


vmlinux-objs-y := $(o0bj)/vmlinux.lds $(o0bj)/head_$(BITS).o $(obj)/misc.o \ 
$(obj)/string.o $(o0bj)/cmdline.o \ 
$(obj)/piggy.o $(obj)/cpuflags.o 


注意 $(obj)/head_$(BITS).0 。 这 意味 着 我 们 将 会 选择 基于 $(BITS) 所 设置 的 文件 执行 链接 
操作 ， 即 head 32.0 或 者 head 64.0。 $(BITS) # arch/x86/Makefile 之 中 根据 .config 文件 
另外 定义 : 


ifeq ($(CONFIG_X86_32),y) 
BITS := 32 


else 


endif 


现在 我 们 知道 从 哪里 开始 了 ， 那 就 来 吧 。 


必要 时 重新 加 载 内 存 段 寄存 器 


正如 上 面 阅 述 的 ， 我 们 先 从 arch/x86/boot/compressed/head_64.S 这 个 汇编 文件 开始 。 首 先 
我 们 看 到 了 在 startup 32 之 前 的 特殊 段 属性 定义 : 


__HEAD 
,Code32 
ENTRY(startup_32) 


这 个 _HEAD 是 一 个 定义 在 头 文件 includel/linux/init.h 中 的 宏 ， 展 开 后 就 是 下 面 这 个 段 的 定 
L: 


#define _ HEAD .section " head. text", "ax" 
其 拥有 .head.text 的 命名 和 ax 标记 。 在 这 里 ， 这 些 标记 告诉 我 们 这 个 段 是 可 执行 的 或 者 


换 种 说 法 ， 包 含 了 代码 。 我 们 可 以 在 arch/x86/boot/rcompressed/vmlinux.lds.S 这 个 链接 脚本 
里 找到 这 个 段 的 定义 : 


SECTIONS 
{ 

. = 0; 

,head .text : { 
_head =. ; 
HEAD_TEXT 
_ehead =. ; 

} 


如 果 你 不 熟悉 GNU LD 这 个 链接 脚本 语言 的 语法 ， 你 可 以 在 这 个 文档 中 找到 更 多 信息 。 简 单 
来 说 ， 这 个 ， 符号 是 一 个 链接 器 的 特殊 变量 - 位 置 计数 器 。 其 被 赋值 为 相对 于 该 段 的 偏 移 。 
在 这 里 ， 我 们 将 位 置 计数 器 赋值 为 0， 这 意味 着 我 们 的 代码 被 链接 到 内 存 的 6 偏 移 处 。 此 


外 ， 我 们 可 以 从 注释 里 找到 更 多 信息 : 


Be careful parts of head_64.S assume startup_32 is at address 0. 


要 小 心 ， head_64.S 中 一 些 部 分 假设 startup_32 位 于 地 址 O° 


好 了 ， 现 在 我 们 知道 我 们 在 哪里 了 ， 接 下 来 就 是 深入 startup_32 函数 的 最 佳 时 机 。 


在 startup_32 函数 的 开始 ， 我 们 可 以 看 到 cld 指令 将 标志 寄存 器 的 pF (方向 标志 ) 位 
清空 。 当 方向 标志 被 清空 ， 所 有 的 串 操 作 指 令 像 stos，scas 等 等 将 会 增加 索引 寄存 器 esi 
或 者 edi 的 值 。 我 们 需要 清空 方向 标志 是 因为 接 下 来 我 们 会 使 用 汇编 的 串 操 作 指 令 来 做 为 页 
表 腾 出 空间 等 工作 。 


在 我 们 清空 ve 标志 后 ， 下 一 步 就 是 从 内 核 加 载 头 中 的 loadflags 字段 来 检查 
KEEP_SEGMENTS 标志 。 你 是 否 还 记得 在 本 书 的 最 初 一 节 ， 我 们 已 经 看 到 过 1loadflags 。 在 那 
里 我 们 检查 了 cAN_USE_HEAP 标记 以 使 用 堆 。 现 在 我 们 需要 检查 KEEP_SEGMENTS 标记 。 这 些 
标记 在 linux 的 引导 协议 文档 中 有 描述 : 


Bit 6 (write): KEEP_SEGMENTS 
Protocol: 2.07+ 
- If 0, reload the segment registers in the 32bit entry point. 
- If 1, do not reload the segment registers in the 32bit entry point. 
Assume that %cs %ds %SS %es are all set to flat segments with 
a base of 0 (or the equivalent for their environment). 


AE 


第 6 位 (3): KEEP_SEGMENTS 

协议 版 本 : 2.07+ 

- 为 0， 在 32 位 入 口 点 重 载 段 寄存 器 

- 为 1， 不 在 32 位 入 口 点 重 载 段 寄存 器 。 假 设 %cs %ds %ss %es 都 被 设 到 基地 址 为 0 的 普通 段 中 (或 者 在 他 们 
的 环境 中 等 价 的 位 置 ) 。 








所 以 ， 如 果 KEEP_SEGMENTS 位 在 loadflags 中 没有 被 设置 ， 我 们 需要 重 置 ds ，ss 和 es 
段 寄 存 器 到 一 个 基地 址 为 6 的 普通 段 中 。 如 下 : 


testb $(1 << 6), BP_loadflags(%esi) 


jnz if 

cli 

movl $(__BOOT_DS), %eax 
movl %eax, %ds 

movl %eax, %es 


movl %eax, %SS 


记 住 _pootps 是 oxis (位 于 全 局 描述 符 表 中 数据 段 的 索引 ) 。 如 果 设 置 了 
KEEP_SEGMENTS ， 我 们 就 跳 转 到 最 近 的 af 标签 ， 或 者 当 没 有 af 标签 ， 则 用 _ BooT_ps 
更 新 段 寄 存 器 。 这 非常 简单 ， 但 是 这 是 一 个 有 趣 的 操作 。 如 果 你 已 经 读 了 前 一 章节 ， 你 或 许 
还 记得 我 们 在 arch/x86/boot/pmjump.S 中 切换 到 保护 模式 的 时 候 已 经 更 新 了 这 些 段 寄存 器 。 
那么 为 什么 我 们 还 要 去 关心 这 些 段 寄存 器 的 值 呢 ?答案 很 简单 ，Linux 内 核 也 有 32 位 的 引导 协 
议 ， 如 果 一 个 引导 程序 之 前 使 用 32 位 协议 引导 内 核 ， MAL startup_32 之 前 的 代码 就 会 被 
忽略 。 在 这 种 情况 下 startup_32 将 会 变 成 引导 程序 之 后 的 第 一 个 入 口 点 ， 不 保证 段 寄 存 器 
会 不 会 处 于 未 知 状态 。 


在 我 们 检查 了 KEEP_SEGMENTS 标记 并 且 给 段 寄 存 器 设置 了 正确 的 值 之 后 ， 下 一 步 就 是 计算 我 

们 代码 的 加 载 和 编译 运行 之 间 的 位 置 偏差 了 。 记 住 setup.1d.S 包含 了 以 下 定义 :在 
.head.text 段 的 开始 ,= 0 。 这 意味 着 这 一 段 代 码 被 编译 成 从 6 地 址 运行 。 我 们 可 以 在 
objdump 工具 的 输出 中 看 到 : 


arch/x86/boot/compressed/vmlinux: file format elf64-x86-64 


Disassembly of section .head.text: 


0000000000000000 <startup_32>: 
OF fc cld 
ale f6 86 11 02 00 00 40 testb $0x40,0x211(%rsi) 


objdump 工具 告诉 我 们 startup 32 的 地 址 是 o 。 但 实际 上 并 不 是 。 我 们 当前 的 目标 是 获 
知 我 们 实际 上 在 哪里 。 在 长 模式 下 ， 这 非常 简单 ， 因 为 其 支持 rip 相对 寻 址 ， 但 是 我 们 当前 
处 于 保护 模式 下 。 我 们 将 会 使 用 一 个 常用 的 方法 来 确定 startup_32 的 地 址 。 我 们 需要 定义 
一 个 标签 并 且 跳 转 到 它 ， 然 后 把 栈 顶 抛 出 到 一 个 寄存 器 中 : 


call label 
label: pop %reg 


在 这 之 后 ， 那 个 寄存 器 将 会 包含 标签 的 地 址 ， 让 我 们 看 看 在 Linux 内 核 中 类 似 的 寻找 
startup_32 地 址 的 代码 : 


leal (BP_scratch+4)(%esi), %esp 
call 1f 

1: popl %ebp 
subl $1b, %ebp 


回忆 前 一 节 ， esi 寄存 器 包含 了 boot params 结构 的 地 址 ， 这 个 结构 在 我 们 切换 到 保护 模 
式 之 前 已 经 被 填充 了 ° bootparams 这 个 结构 体 包含 了 一 个 特殊 的 字段 scratch ? 其 偏 移 量 
为 gxle4 。 这 个 4 字 节 的 区 域 将 会 成 为 call 指令 的 临时 栈 。 我 们 把 scratch 的 地 址 加 4 
BA esp 寄存 器 。 我 们 之 所 以 在 BP scratch 基础 上 加 4 是 因为 ， 如 之 前 所 说 的 ， 这 将 成 


为 一 个 临时 的 栈 ， 而 在 x86_64 架构 下 ， 栈 是 自 顶 向 下 生长 的 。 所 以 我 们 的 栈 指针 就 会 指向 
栈 顶 。 接 下 来 我 们 就 可 以 看 到 我 上 面 描述 的 过 程 。 我 们 跳 转 到 1f 标签 并 且 把 该 标签 的 地 址 
放 入 ebp 寄存 器 ， 因 为 在 执行 call 指令 之 后 我 们 把 返回 地 址 放 到 了 栈 顶 。 那 么 ， 目 前 我 
们 拥有 sp 标签 的 地 址 ， 也 能 够 很 容易 得 到 startup_32 的 地 址 。 我 们 只 需要 把 我 们 从 栈 里 
得 到 的 地 址 减 去 标签 的 地 址 : 


startup_32 (0x0) +----------------------- + 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 

1f (0x0 + 1f offset) +----------------------- + %ebp - 实际 物理 地 址 
| | 
| | 
fo odee somo sebensseseoaes + 


startup_32 被 链接 为 在 oxo 地 址 运行 ， 这 意味 着 1f 的 地 址 为 oxo + 1f 的 偏 移 量 。 实 际 
上 偏 移 量 大 概 是 gx22 字 节 。 ebp 寄存 器 包含 了 1f 标签 的 实际 物理 地 址 。 所 以 如 果 我 们 
从 ebp PRA 1f ， 我 们 就 会 得 到 startup_32 的 实际 物理 地 址 。Linux 内 核 的 引导 协议 描 
述 了 保护 模式 下 的 内 核 基 地 址 是 gx199999 。 我 们 可 以 用 gdb 来 验证 。 让 我 们 启动 调试 器 并 
且 在 if 的 地 址 ox100022 添加 断 点 。 如 果 这 是 正确 的 ， 我 们 将 会 看 到 在 ebp 寄存 器 中 值 


为 0x100022 


$ gdb 

(gdb)$ target remote :1234 
Remote debugging using :1234 
oxoooofffO in ?? () 

(gdb)$ br *0x100022 
Breakpoint 1 at 0x100022 
(gdb)$ c 

Continuing. 


Breakpoint 1, 0x00100022 in ?? () 


(gdb)$ ir 

eax 0x18 0x18 

ecx 0x0 0x0 

edx 0x0 0x0 

ebx 0x0 0x0 

esp 0x144a8 0x144a8 
ebp 0x100021 0x100021 
esi 0x142c0 0x142c0 
edi 0x0 0x0 

eip 0x100022 0x100022 
eflags 0x46 [ PF ZF ] 

cs 0x10 0x10 

SS 0x18 0x18 

ds 0x18 0x18 

es 0x18 0x18 

fs 0x18 0x18 

gs 0x18 0x18 


如 果 我 们 执行 下 一 条 指令 subl $1b, %eop ， 我 们 将 会 看 到 : 


nexti 


ebp 0x100000 0x100000 


好 了 ， 那 是 对 的 。 startup_32 的 地 址 是 ox1ooo00 。 在 我 们 知道 了 startup_32 的 地 址 之 
后 ， 我 们 可 以 开始 准备 切换 到 长 模式 了 。 我 们 的 下 一 个 目标 是 建立 栈 并 且 确 认 CPU 对 长 模式 
和 SSE 的 支持 。 


栈 的 建立 和 CPU 的 确认 


如 果 不 知道 startup_32 标签 的 地 址 ， 我 们 就 无 法 建立 栈 。 我 们 可 以 把 栈 看 作 是 一 个 数组 ， 
并 且 栈 指针 寄存 器 esp 必须 指向 数组 的 底部 。 当 然 我 们 可 以 在 自己 的 代码 里 定义 一 个 数组 ， 
但 是 我 们 需要 知道 其 丨 实地 址 来 正确 配置 栈 指针 。 让 我 们 看 一 下 代码 : 


movl $boot_stack_end, %eax 
addl %ebp, %eax 
movl %eax, %esp 


boots_stack_end 标签 被 定义 在 同一 个 汇编 文件 arch/x86/boot/compressed/head_64.S 中 ， 
位 于 .bss 段 : 


,bss 

.balign 4 
boot_heap: 

. fill BOOT_HEAP_SIZE, 1, 0 
boot_stack: 

. fill BOOT_STACK_SIZE, 1, 0 
boot_stack_end: 


首先 ， 我 们 把 boot_stack_end 22) eax 寄存 器 中 。 那 么 ex 寄存 器 将 包含 
boot_stack_end 链接 后 的 地 址 或 者 说 Oxo + boot_stack_end 。 为 了 得 到 boot_stack_end 的 
实际 地 址 ， 我 们 需要 加 上 startup_32 的 实际 地 址 。 回 忆 一 下 ， 前 面 我 们 找到 了 这 个 地 址 并 
且 把 它 存 到 了 ebp 寄存 器 中 。 最 后 eax 寄存 器 将 会 包含 boot_stack_end 的 实际 地 址 ， 
我 们 只 需要 将 其 加 到 栈 指针 上 。 


在 外 面 建立 了 栈 之 后 ， 下 一 步 是 CPU 的 确认 。 了 既然 我 们 将 要 切换 到 长 模式 ， 我 们 需要 检查 
CPU 是 否 支 持 长 模式 和 sse 。 我 们 将 会 在 跳 转 到 verify_cpu 函数 之 后 执行 : 


call verify_cpu 
testl %eax, %eax 
jnz no_longmode 


这 个 函数 定义 在 arch/x86/kernel/verify_cpu.S 中 ， 只 是 包含 了 几 个 对 cpuid 指令 的 调用 。 该 
指令 用 于 获取 处 理 器 的 信息 。 在 我 们 的 情况 下 ， 它 检查 了 对 RRA 和 SSE 的 支持 ， 通 过 
eax 寄存 器 返回 0 表示 成 功 ，1 表 示 失 败 。 
如 果 eax 的 值 不 是 0， 我 们 就 跳 转 到 no_longmode 标签 ， 用 hit PU FAR 
会 发 生硬 件 中 断 : 

no_longmode: 

1: 


hlt 
jmp 1b 


如 果 eax 的 值 为 0， 万 事 大 吉 ， 我 们 可 以 继续 。 


计算 重 定位 地 址 


一 步 是 在 必要 的 时 候 计 算 解 压缩 之 后 的 地 址 。 首 先 ， 我 们 需要 知道 内 核 重 定位 的 意义 。 我 
们 已 经 知道 Linux 内 核 的 32 位 入 口 点 地 址 位 于 oxi90000 。 但 是 那 是 一 个 32 位 的 入 口 。 默 认 
的 内 核 基 地 址 由 内 核 配 置 项 CONFIG_PHYSICAL_START 的 值 所 确定 ， 其 默认 值 为 ”gx1600066 或 
16 MB 。 这 里 的 主要 问题 是 如 果 内 核 崩 演 了 ， AAT heey nae 救 
ram 来 进行 kdump。Linux 内 核 提 供 了 特殊 的 配置 选项 以 解决 此 问题 - CONFIG_RELOCATABLE 
。 我 们 可 以 在 内 核 文 档 中 找到 : 


This builds a kernel image that retains relocation information 
so it can be loaded someplace besides the default 1MB. 


Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address 
it has been loaded at and the compile time physical address 
(CONFIG_PHYSICAL_START) is used as the minimum location. 


这 建立 了 一 个 保留 了 重 定向 信息 的 内 核 镜像 ， 这 样 就 可 以 在 默认 的 1MB 位 置 之 外 加 载 了 。 


注意 : 如 果 CONFIG_RELOCATABLE=y， 那么 内 核 将 会 从 其 被 加 载 的 位 置 运行 ， 编 译 时 的 物理 地 址 (CONFIG_PH 
YSICAL_START) 将 会 被 作为 最 低地 址 位 置 的 限制 。 


简单 来 说 ， 这 意味 着 相同 配置 下 的 Linux 内 核 可 以 从 不 同 地 址 被 启动 。 这 是 通过 将 程序 以 位 
置 无 关 代码 的 形式 编译 来 达到 的 。 如 果 我 们 参考 /arch/x86/boot/compressed/Makefile， 我 们 
将 会 看 到 解压 器 的 确 是 用 -fpIc 标记 编译 的 : 


KBUILD_CFLAGS += -fno-strict-aliasing -fPIC 


当 我 们 使 用 位 置 无 关 代 码 时 ， 一 段 代 码 的 地 址 是 由 一 个 控制 地 址 加 上 程序 计数 器 计算 得 到 

的 。 我 们 可 以 从 任意 一 个 地 址 加 载 使 用 这 种 方式 寻 址 的 代码 。 这 就 是 为 什么 我 们 需要 获得 
startup_32 的 实际 地 址 。 现 在 让 我 们 回 到 Linux 内 核 代码 。 我 们 目前 的 目标 是 计算 出 内 核 解 
压 的 地 址 。 这 个 地 址 的 计算 取决 于 内 核 配置 项 cONFIG RELOCATABLE 。 让 我 们 看 代码 : 


#ifdef CONFIG_RELOCATABLE 
movl %ebp, %ebx 


movl BP_kernel_alignment(%esi), %eax 
decl %eax 
addl %eax, %ebx 
notl %eax 
andl %eax, %ebx 
cmpl $LOAD_PHYSICAL_ADDR, %ebx 
jge 1f 
#endif 


movl $LOAD_PHYSICAL_ADDR, %ebx 


addl $z_extract_offset, %ebx 


记 住 ebp 寄存 器 的 值 就 是 startup_32 标签 的 物理 地 址 。 如 果 在 内 核 配置 中 
CONFIG_RELOCATABLE 内 核 配 置 项 开启 ， 我 们 就 把 这 个 地 址 放 到 ebx ， 对 齐 到 om 
的 整数 倍 ， 然 后 和 LoAD_PHYSICAL_ADDR 的 值 比较 。 LOAD_PHYSICAL ADDR 宏 定义 在 头 文件 
arch/x86/include/asm/boot.h 中 ， 如 下 : 


#define LOAD_PHYSICAL_ADDR ((CONFIG_PHYSICAL_START \ 
+ (CONFIG_PHYSICAL_ALIGN - 1)) \ 
& ~(CONFIG_PHYSICAL_ALIGN - 1)) 


我 们 可 以 看 到 该 宏 只 是 展开 成 对 齐 的 CONFIG_PHYSICAL_ALIGN 值 ， 其 表示 了 内 核 加 载 位 置 的 物 
理 地 址 。 在 比较 了 LOAD_PHYSICAL ADDR 和 ebx 的 值 之 后 ， 我 们 给 startup_32 加 上 偏 移 来 
获得 解压 内 核 镜像 的 地 址 。 如 果 CONFIG_RELOCATABLE 选项 在 内 核 配置 时 没有 开启 ， 我 们 就 直 
接 将 默认 的 地 址 加 上 z extract offset 。 


在 前 面 的 操作 之 后 ，ebp 包含 了 我 们 加 载 时 的 地 址 ，ebx 被 设 为 内 核 解 压缩 的 目标 地 址 。 


进入 长 模式 前 的 准备 工作 


在 我 们 得 到 了 重 定位 内 核 镜像 的 基地 址 之 后 ， 我 们 需要 做 切换 到 64 位 模式 之 前 的 最 后 准备 。 
首先 ， 我 们 需要 更 新 全 局 描述 符 表 : 


leal gdt(%ebp), %eax 
movl %eax, gdt+2(%ebp) 
lgdt gdt (%ebp) 


在 这 里 我 们 把 ebp 寄存 器 加 上 gdt 的 偏 移 存 到 eax 寄存 器 。 接 下 来 我 们 把 这 个 地 址 放 到 
ebp 加 上 gdt+2 偏 移 的 位 置 上 ， 并 且 用 igt HARA 全 局 描述 符 表 。 为 了 理解 这 个 神奇 
的 gt 偏 移 量 ， 我 们 需要 关注 全 局 描述 符 表 的 定义 。 我 们 可 以 在 同一 个 源 文件 中 找到 其 定 
汉 


.data 


gdt : 

,Word gdt_end - gdt 

. Long gdt 

.word 0 

. quad 0x0000000000000000 /* NULL descriptor */ 

. quad Ox00af 9a000000F FFF /* __KERNEL_CS */ 

. quad Ox00cfF92000000F FFF /* __KERNEL_DS */ 

. quad 0x0080890000000000 /* TS descriptor */ 

. quad 0x0000000000000000 /* TS continued */ 
gdt_end: 


我 们 可 以 看 到 其 位 于 data 段 ， 并 且 包 含 了 5 个 描述 符 : null 、 内 核 代 码 段 、 内 核 数 据 段 
和 其 他 两 个 任务 描述 符 。 我 们 已 经 在 上 一 章节 载 入 了 全 局 描述 符 表 ， 和 我 们 现在 做 的 差 不 

多 ， 但 是 将 描述 符 改 为 cs.L = 1 cs.D = 9 从 而 在 64 位 模式 下 执行 。 Saas > 

gdt 的 定义 从 两 个 字 节 开始 : gdt_end - gdt ? 代表 了 gdt 表 的 最 后 一 个 字 节 ， 或 者 说 表 
的 范围 。 接 下 来 的 4 个 字 节 和 包含 了 gat 的 基地 址 。 记 住 全 局 描述 符 表 保存 在 48 位 GDTR- 全 局 措 
述 符 表 寄 存 器 中 ， 由 两 个 部 分 组 成 : 


。 wm ak HEA HY Ks (16 位 ) 
one 竺 表 的 基 址 (3242) 


所 以 ， 我 们 把 gat 的 地 址 放 到 eax 寄存 器 ， 然 后 存 到 long gdt 或 者 gdt+2 。 现 在 我 们 
已 经 建立 了 cor 寄存 器 的 结构 ， 并 且 可 以 用 igt WARA 全 局 描述 符 表 To 


在 我 们 载 入 全 局 


局 描述 符 表 之 后 ， 我 们 必须 启用 PAE 模式 。 方 法 是 将 cr4 寄存 器 的 值 传 入 
eax ， 将 第 5 位 置 1， 


然后 再 写 回 cr4 。 


movl %cr4, %eax 
orl $X86_CR4_PAE, %eax 
movl %eax, %cr4 


现在 我 们 已 经 接近 完成 进入 64 位 模式 前 的 所 有 准备 工作 了 。 最 后 一 步 是 建立 页 表 ， 但 是 在 此 
之 前 ， 这 里 有 一 些 关于 长 模式 的 知识 。 


ak} h 
ZN 
长 模式 是 X86 64 系列 处 理 器 的 原生 模式 。 首 先 让 我 们 看 一 看 x86 .64 和 x86 的 一 些 区 别 。 


64 位 模式 提供 了 一 些 新 特性 ， 比 如 : 


e 从 rs 到 ris 8 个 新 的 通用 寄存 器 ， 并 且 所 有 通用 寄存 器 都 是 64 位 的 了 。 
e 64 位 指令 指针 - RIP ; 
o 新 的 操作 模式 - 长 模式 


© 64 位 地 址 和 操作 数 ; 
© RIP 相对 寻 址 (我 们 将 会 在 接 下 来 的 章节 看 到 一 个 例子 ). 


长 模式 是 一 个 传统 保护 模式 的 扩展 ， 其 由 两 个 子 模式 构成 : 


© 64 位 模式 
e 兼容 模式 


为 了 切换 到 64 位 模式 ， 我 们 需要 完成 以 下 操作 : 


2 A| PAE; 
页 表 并 且 将 顶级 页 表 的 地 址 放 入 cr3 寄存 器 ; 


立 
用 EFER.LME ; 
用 


我 们 已 经 通过 设置 cra 控制 寄存 器 中 的 PAE 位 启动 PAE 了 。 在 下 一 个 段落 ， 我 们 就 要 建 
立 页 表 的 结构 了 。 


初期 页 表 初 始 化 


现在 ， 我 们 已 经 知道 了 在 进入 64 位 模式 之 前 ， 我 们 需要 先 建立 页 表 ， 那 么 就 让 我 们 看 看 如 
何 建立 初期 的 46 BARR 


lr 


注意 : 我 不 会 在 这 里 解释 虚拟 内 存 的 理论 ， 如 果 你 想 知 道 更 多 ， 查 看 本 节 最 后 的 链接 
Linux 内 核 使 用 4 级 页 表 ， 通 常 我 们 会 建立 6 个 页 表 : 


e 1 个 PML4 或 称 为 ”4 级 页 映射 表 ， 包 含 1 个 项 ; 

e 1 个 pop 或 称 为 ”页 目录 指针 表 ， 包 含 4 个 项 ; 

e 4 个 页 目录 表 ， 一 共 包 含 2048 个 项 ; 
让 我 们 看 看 其 实现 方式 。 首 先 我 们 在 内 存 中 为 页 表 清 理 一 块 缓存 。 每 个 表 都 是 4696 字 节 ， 
所 以 我 们 需要 24 KB 的 空间 : 


leal pgtable(%ebx), %edi 


xorl %eax, %eax 
movl $((4096*6)/4), %ecx 
rep stosl 


我 们 把 和 ebx 相关 的 pgtable 的 地 址 放 到 edi 寄存 器 中 ， 清 空 eax 寄存 器 ， 并 将 ecx 
赋值 为 6144 ° rep stosl 指令 将 会 把 eax 的 值 写 到 edi 指向 的 地 址 ， 然 后 给 edi 加 
4 > ecx m4 ° BE BA ecx 小 于 等 于 0。 所 以 我 们 才 把 6144 赋值 给 ecx © 


pgtable 定义 在 arch/x86/boot/compressed/head_64.S 的 最 后 : 


,Section ".pgtable","a",@nobits 
.balign 4096 

pgtable: 
.fill 6*4096, 1, 0 


我 们 可 以 看 到 ， 其 位 于 .pgtable 段 ， 大 小 为 24KB 。 


在 我 们 为 pgtable 分 配 了 空间 之 后 ， 我 们 可 以 开始 构建 顶级 页 表 - PML4 


leal pgtable + O(%ebx), %edi 
leal 0x1007 (%edi), %eax 
movl %eax, O(%edi) 


还 是 在 这 里 ， 我 们 把 和 ebx 相关 的 ， 或 者 说 和 startup_32 相关 的 pgtable 的 地 址 放 到 
ebi 寄存 器 。 接 下 来 我 们 把 相对 此 地 址 偏 移 gx1607 的 地 址 放 到 eax 寄存 器 中 。 0x1007 
是 PMLA 的 大 小 4096 加 上 7 。 这 里 的 7 代表 了 pua 的 项 标记 。 在 我 们 这 里 ， 这 些 标 
记 是 PRESENT+RW+USER 。 在 最 后 我 们 把 第 一 个 pop (页 目录 指针 ) ”项 的 地 址 写 到 pma Pe 


在 接 下 来 的 一 步 ， 我 们 将 会 在 页 目录 指针 (pope) 表 〈3 级 页 表 ) 建立 4 个 带 有 


PRESENT+RW+USE 标记 的 Page Directory (2 级 页 表 ) WM: 


leal pgtable + Ox1000(%ebx), %edi 
leal 0x1007 (%edi), %eax 
movl $4, %ecx 
1: movl %eax, Ox00(%edi) 
addl $0x00001000, %eax 
addl $8, %edi 
decl %ECX 
jnz 1b 


我 们 把 3 级 页 目录 指针 表 的 基地 址 (从 pgtable 表 偏 移 4096 或 者 oxi000 ) HF) edi ， 
把 第 一 个 2 级 页 目录 指针 表 的 首 项 的 地 址 放 到 eax 寄存 器 。 把 4 赋值 给 ex 寄存 器 ， 其 
将 会 作为 接 下 来 循环 的 计数 器 ， 然 后 将 第 一 个 页 目录 指针 项 写 到 edi 指向 的 地 址 。 之 后 ， 
edi 将 会 包含 带 有 标记 ox7 的 第 一 个 页 目录 指针 项 的 地 址 。 接 下 来 我 们 就 计算 后 面 的 几 个 
页 目录 指针 项 的 地 址 ， 每 个 占 8 字 节 ， 把 地 址 赋值 给 eax ， 然 后 回 到 循环 开头 将 其 写 入 
edi 所 在 地 址 。 建 立 页 表 结 构 的 最 后 一 步 就 是 建立 2048 个 2MB 页 的 页 表 项 。 


leal pgtable + 0x2000(%ebx), %edi 
movl $0x00000183, %eax 
movl $2048, %ecx 
1: movl %eax, O(%edi) 
addl $0x00200000, %eax 
addl $8, %edi 
decl %ECX 
jnz 1b 


在 这 里 我 们 做 的 几乎 和 上 面 一 样 ， 所 有 的 表 项 都 带 着 标记 - $0x00000183 - PRESENT + WRITE + 
MBZ 。 最 后 我 们 将 会 拥有 2048 个 2MB 大 的 页 ， 或 者 说 : 


>>> 2048 * 0x00200000 
4294967296 


一 个 46 页 表 。 我 们 刚刚 完成 我 们 的 初期 页 表 结构 ， 其 映射 了 46 大 小 的 内 存 ， 现 在 我 们 可 
以 把 高 级 页 表 PML4 的 地 址 放 到 cr3 寄存 器 中 了 : 


leal pgtable(%ebx), %eax 
movl %eax, %cr3 


这 样 就 全 部 结束 了 。 所 有 的 准备 工作 都 已 经 完成 ， 我 们 可 以 开始 看 如 何 切换 到 长 模式 了 。 


切换 到 长 模式 
首先 我 们 需要 设置 MSR 中 的 EFER.LME 标记 为 oxcoooo0so 


movl $MSR_EFER, %ecx 
rdmsr 

btsl $_EFER_LME, %eax 
wrmsr 


在 这 里 我 们 把 MSR_EFER 标记 (在 arch/x86/include/uapi/asm/msr-index.h 中 定义 ) 放 到 

ecx 寄存 器 中 ， 然 后 调用 rdmsr 指令 读 取 MSR 寄存 器 。 在 rdmsr 执行 之 后 ， 我 们 将 会 获 
得 edx:eax 中 的 结果 值 ， 其 取决 于 ecx 的 值 。 我 们 通过 btsl 指令 检查 EFER_LME 位 ， 并 
且 通 过 wrmsr 指令 将 eax 的 数据 写 入 usr 寄存 器 


一 步 我 们 将 内 核 段 代 码 地 址 入 栈 (我 们 在 GDT 中 定义 了 ) ， 然 后 将 startup_ 64 的 地 址 导 


入 eax ° 


pushl $__ KERNEL_CS 
leal startup_64(%ebp), %eax 


sy 


在 这 之 后 我 们 把 这 个 地 址 入 栈 然 后 通过 设置 cro 寄存 器 中 的 pe 和 PE 启用 分 


movl $(X86_CRO_PG | X86_CRO_PE), %eax 
movl %eax, %CrO 


然后 执行 : 

lret 
a4 o iE Ry — HRN CHA startup 64 函数 的 地 址 入 栈 ， 在 iret 指令 之 后 ，CPU 取出 
了 其 地 址 跳 转 到 那里 。 


这 些 步 骤 之 后 我 们 最 后 来 到 了 64 位 模式 : 


,Code64 
.Org 0x200 
ENTRY(startup_64) 


就 是 这 样 ! 
心 结 


这 是 linux 内 核 启 动 流程 的 第 4 部 分 。 如 果 你 有 任何 的 问题 或 者 建议 ， 你 可 以 留言 ， 也 可 以 直 
接 发 消息 给 我 twitter 或 者 创建 一 个 issue。 


下 一 节 我 们 将 会 看 到 内 核 解 压缩 流程 和 其 他 更 多 。 


如 果 你 发 现 文中 描述 有 任何 问题 ， 请 提交 一 个 PR 到 linux-insides-zh ° 


相关 链接 


e Protected mode 

e Intel® 64 and IA-32 Architectures Software Developer’s Manual 3A 
e GNU linker 

e SSE 

e Paging 

e Model specific register 

e fill instruction 


过 渡 到 64 位 模式 


e Previous part 

e Paging on osdev.org 
e Paging Systems 
x86 Paging Tutorial 
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内 核 引 导 过 程 .Part 5. 


内 核 解压 


这 是 内 核 引导 过 程 系列 文章 的 第 五 部 分 。 在 前 一 部 分 我 们 看 到 了 切换 到 64 位 模式 的 过 程 ， 在 这 
一 部 分 我 们 会 从 这 里 继续 。 我 们 会 看 到 跳 进 内 核 代 码 的 最 后 步骤 : 内 核 解 压 前 的 准备 、 重 定 
位 和 直接 内 核 解 压 。 所 以 ... 让 我 们 再 次 深入 内 核 源码 。 


内 核 解 压 前 的 准备 


我 们 停 在 了 跳 转 到 64 位 ATA startup_64 的 跳 转 之 前 ， 它 在 源 文 件 
arch/x86/boot/compressed/head 64.S 里 面 。 在 之 前 的 部 分 ， 我 们 已 经 在 startup_32 里 面 看 
到 了 到 startup_64 的 跳 转 : 





pushl $__ KERNEL_CS 
leal startup_64(%ebp), %eax 


pushl %eax 
lret 


由 于 我 们 加 载 了 新 的 全 局 描述 符 表 并 且 在 其 他 模式 有 CPU 的 模式 转换 (在 我 们 这 里 是 64 位 模 
A) ， 我 们 可 以 在 startup_64 的 开头 看 到 数据 段 的 建立 : 


.code64 
.Org 0x200 
ENTRY(startup_64) 

xorl %eax, %eax 
movl %eax, %ds 
movl %eax, %es 
movl %eax, %SS 
movl %eax, %fs 
movl %eax, %gs 


除 cs 之 外 的 段 寄存 器 在 我 们 进入 长 模式 时 已 经 重 置 。 


下 一 步 是 计算 内 核 编译 时 的 位 置 和 它 被 加 载 的 位 置 的 差 


#ifdef CONFIG_RELOCATABLE 
leaq startup_32(%rip), %rbp 
movl BP_kernel_alignment(%rsi), %eax 
decl %eax 
addq %rax, %rbp 
notd %rax 
andq %rax, %rbp 
cmpq $LOAD_PHYSICAL_ADDR, %rbp 
jge 1f 

#endif 
movq $LOAD_PHYSICAL_ADDR, %rbp 


movl BP_init_size(%rsi), %ebx 
subl $_end, %ebx 
addq %rbp, %rbx 


rop 包含 了 解压 后 内 核 的 起 始 地 址 ， 在 这 段 代码 执行 之 后 rbx 会 包含 用 于 解压 的 重 定位 内 核 
代码 的 地 址 。 我 们 已 经 在 startup_32 看 到 类 似 的 代码 (你 可 以 看 之 前 的 部 分 计算 重 定位 地 
I) ， 但 是 我 们 需要 再 做 这 个 计算 ， 因 为 引导 加 载 器 可 以 用 64 位 引导 协议 ， 而 startup_32 在 
这 种 情况 下 不 会 执行 。 


下 一 步 ， 我 们 可 以 看 到 栈 指针 的 设置 和 标志 寄存 器 的 重 置 : 


leaq boot_stack_end(%rbx), %rsp 


pushq $0 
popfq 


如 上 所 述 ，rpx 寄存 器 包含 了 内 核 解压 代码 的 起 始 地 址 ， 我 们 把 这 个 地 址 

的 boot_stack_entry 偏 移 地 址 相 加 放 到 表示 栈 顶 指针 的 rsp 寄存 器 。 在 这 一 步 之 后 ， 栈 就 是 
正确 的 。 你 可 以 在 汇编 源码 文件 arch/x86/boot/compressed/head 64.S 的 末尾 找 

到 boot_stack_end 的 定义 : 


,bss 

.balign 4 
boot_heap: 

. fill BOOT_HEAP_SIZE, 1, 0 
boot_stack: 

. fill BOOT_STACK_SIZE, 1, 0 
boot_stack_end: 


它 在 .bss 节 的 末尾 ， 就 在 .pgtable ay 9 如 果 你 查看 
arch/x86/boot/compressed/vmlinux.lds.S 链接 脚本 ， 你 会 找到 .pss 和 .pgtable 的 定义 。 
由 于 我 们 设置 了 栈 ， 在 我 们 计算 了 解压 了 的 内 核 的 重 定位 地 址 后 ， 我 们 可 以 复制 压缩 了 的 内 
核 到 以 上 地 址 。 在 查看 细节 之 前 ， 我 们 先 看 这 段 汇编 代码 : 


pushq %rsi 
leaq (_bss-8)(%rip), %rsi 
leaq (_bss-8)(%rbx), %rdi 


movq $_bss, %rcx 
shrq $3, %rcx 
std 

rep movsq 

cld 


popq %rsi 


首先 我 们 把 rsi 压 进 栈 。 eo rsi 的 值 ， 因 为 这 个 寄存 器 现在 存放 指 


向 boot _params 的 指针 ， 包含 引导 相关 数据 的 on 吉 构 体 (你 一 定 记 得 这 个 结构 体 ， 我 
re a a 。 在 代码 的 结尾 ， 我 们 会 重新 恢复 指向 boot_params 的 
指针 到 rsi . 


接 下 来 两 个 leag 指令 用 _bss - 8 偏 移 和 rip 和 ros 计算 有 效 地 址 并 存放 到 rsi 和 rdi .我 
们 为 什么 要 计算 这 些 地 址 ? 实际 上 上， 压缩 了 的 代码 镜像 存放 在 这 份 复制 了 的 代码 

(从 startup_32 到 当前 的 代码 ) 和 解压 了 的 代码 之 间 。 你 可 以 通过 查看 链接 脚本 
arch/x86/boot/compressed/vmlinux.lds.S 验证 : 


== 0; 
.head.text : { 
_head = . ; 
HEAD_TEXT 
_ehead =. ; 
} 
.rodata..compressed : { 
*(.rodata. .compressed) 


} 
text : { 
_text = .; f= Next. *7 
*(,. text) 
“(text *) 
etext =. ; 
} 


ae 


注意 .head.text 节 和 包含 了 startup_32 . 你 可 以 从 之 前 的 部 分 回忆 起 它 : 


__HEAD 
.code32 
ENTRY(startup_32) 


2 


s} 


包含 解压 代码 : 


dt 


. text 


text 
relocated: 


Pa 
* Do the decompression, and jump to the new kernel.. 
if 


.rodata..compressed 包含 了 压缩 了 的 内 核 镜像 。 所 以 rsi LS _bss - 8 的 绝对 地 

址 ，rdi EA bss - 8 的 重 定位 的 相对 地 址 。 在 我 们 把 这 些 地 址 放 入 寄存 器 时 ， 我 们 

把 _bss 的 地 址 放 到 了 rex 寄存 器 。 正 如 你 在 vmlinux.1lds.s 链接 脚本 中 看 到 了 一 样 ， 它 和 设 
置 /内 核 代码 一 起 在 所 有 节 的 末尾 。 现 在 我 们 可 以 开始 用 movsq 指令 每 次 8 字 节 地 

从 rsi 到 rdi 复制 代码 。 


注意 在 数据 复制 前 有 std is A: 它 设置 DF 标志 ， 意 味 着 rsi 和 rdi 会 递减 。 换 句 话 说， 我 
们 会 从 后 往 前 复制 这 些 字 节 。 最 后 ， 我 们 用 cld 指令 清除 DF 标志 ， 并 恢 


复 boot_params 到 rsi. 


现在 我 们 有 ,text 节 的 重 定位 后 的 地 址 ， 我 们 可 以 跳 到 那里 : 


leaq relocated(%rbx), %rax 
jmp *%rax 


在 内 核 解 压 前 的 最 后 准备 


在 上 一 段 我 们 看 到 了 .text 节 从 relocated 标签 开始 。 它 做 的 第 一 件 事 是 清空 .bss 节 : 


xorl %eax, %eax 
leaq _bss(%rip), %rdi 
leaq _ebss(%rip), %rcx 
subq %rdi, %rcx 


shrq $3, %rcx 
rep stosq 


我 们 要 初始 化 bss 节 ， 因 为 我 们 很 快要 跳 转 到 C 代 码 。 这 里 我 们 就 清空 eax ， 把 _bss 的 地 
址 放 到 rdi ， 把 _ebss 放 到 rex ， 然 后 用 rep stosq #2 


o 


最 后 ， 我 们 可 以 调用 extract kernel 函数 : 


pushq %r SL 

movq %rsi, %rdi 

leaq boot_heap(%rip), %rsi 
leaq input_data(%rip), %rdx 


movl $z_input_len, %ecx 
movq %rbp, %r8 

movq $z_output_len, %r9 
call extract_kernel 


popq %rsi 


我 们 再 一 次 设置 rdi 为 指向 boot_params 结构 体 的 指针 并 把 它 保存 到 栈 中 。 同 时 我 们 设 

置 rsi 指向 用 于 内 核 解 压 的 区 域 。 最 后 一 步 是 准备 extract_kernel 的 参数 并 调用 这 个 解压 内 
核 的 函数 。 extract_kernel 437 arch/x86/boot/compressed/misc.c 源 文件 定义 并 有 六 个 参 
数 : 


e rmode -指向 boot params 结构 体 的 指针 ， boot_params 被 引导 加 载 器 填充 或 在 早期 内 
核 初 始 化 时 填充 

e heap -指向 早期 启动 堆 的 起 始 地 址 poot_heap 的 指针 

èe input data - 指向 压缩 的 内 核 ， 即 arch/x86/boot/compressed/vmlinux.bin.bz2 的 指针 

© input_len -压缩 的 内 核 的 大 小 

© output -解压 后 内 核 的 起 始 地 址 

e output len - 解压 后 内 核 的 大 小 


所 有 参数 根据 System V Application Binary Interface 通过 寄存 器 传递 。 我 们 已 经 完成 了 所 有 
的 准备 工作 ， 现 在 我 们 可 以 看 内 核 解 压 的 过 程 。 


内 核 解压 


就 像 我 们 在 之 前 的 段落 中 看 到 了 那样 ， extract_kernel 函数 在 源 文 件 
arch/x86/boot/compressed/misc.c 定义 并 有 六 个 参数 。 正 如 我 们 在 之 前 的 部 分 看 到 的 ， 这 个 
郊 数 从 图 形 / 控 制 台 初始 化 开始 。 我 们 要 再 次 做 这 件 事 ， 因 为 我 们 不 知道 我 们 是 不 是 从 实 模 式 
开始 ， 或 者 是 使 用 了 引导 加 载 器 ， 或 者 引导 加 载 器 用 了 32 位 还 是 64 位 启动 协议 。 


在 最 早 的 初始 化 步骤 后 ， 我 们 保存 空闲 内 存 的 起 始 和 末尾 地 址 。 


free_mem_ptr = heap; 
free_mem_end_ptr = heap + BOOT_HEAP_SIZE; 


在 这 里 heap 是 我 们 在 arch/x86/boot/compressed/head_64.S 得 到 的 extract_kernel 函数 
的 第 二 个 参数 : 


leaq boot_heap(%rip), %rsi 


如 上 所 述 ，boot_heap 定义 为 : 


boot_heap: 
.fill BOOT_HEAP_SIZE, 1, © 


在 这 里 BooT_HEAP_SIZE 是 一 个 展开 为 ox10000 (对 bzip2 内 核 是 ox400000 ) 的 宏 ， 代 表 堆 的 大 
小 o 


在 堆 指针 初始 化 后 ， 下 一 步 是 从 arch/x86/boot/compressed/kaslr.c 调 

用 choose_random_location 函数 。 我 们 可 以 从 函数 名 猜 到 ， 它 选择 内 核 镜像 解压 到 的 内 存 地 
址 。 看 起 来 很 奇怪 ， 我 们 要 寻找 甚至 是 选择 内 核 解压 的 地 址 ， 但 是 Linux 内 核 支 持 KASLR， 为 
了 安全 ， 它 允许 解压 内 核 到 随机 的 地 址 。 


在 这 一 部 分 ， 我 们 不 会 考虑 Linux 内 核 的 加 载 地 址 的 随机 化 ， 我 们 会 在 下 一 部 分 讨论 。 
现在 我 们 回头 看 misc.c. 在 获得 内 核 镜 像 的 地 址 后 ， 需 要 有 一 些 检查 以 确保 获得 的 随机 地 址 是 
正确 对 齐 的 ， 并 且 地 址 没有 错误 : 


if ((unsigned long)output & (MIN_KERNEL_ALIGN - 1)) 
error("Destination physical address inappropriately aligned"); 


if (virt addr & (MIN_KERNEL_ALIGN - 1)) 
error("Destination virtual address inappropriately aligned"); 


if (heap > Ox3fffffffffffUyUL) 
error("Destination address too large"); 


if (virt addr + max(output_len, kernel_total_size) > KERNEL_IMAGE_SIZE) 
error("Destination virtual address is beyond the kernel mapping area"); 


if ((unsigned long)output != LOAD_PHYSICAL_ADDR) 
error( "Destination address does not match LOAD_PHYSICAL_ADDR"); 


if (virt_addr != LOAD_PHYSICAL_ADDR) 
error("Destination virtual address changed when not relocatable"); 


在 所 有 这 些 检 查 后 ， 我 们 可 以 看 到 熟悉 的 消息 : 


Decompressing Linux... 


然后 调用 解压 内 核 的 _ decompress 函数 : 


__decompress(input_data, input_len, NULL, NULL, output, output_len, NULL, error); 


__decompress 哆 数 的 实现 取决 于 在 内 核 编译 期 间 选 择 什么 压缩 算法 : 


#ifdef CONFIG_KERNEL_GZIP 
#include "../../../../1ib/decompress_inflate.c" 


#endif 


#ifdef CONFIG_KERNEL_BZIP2 
#include "../../../../1ib/decompress_bunzip2.c" 


#endif 


#ifdef CONFIG_KERNEL_LZMA 
#include "../../../../1ib/decompress_unlzma.c" 


#endif 


#ifdef CONFIG_KERNEL_XZ 
#include ur 7n /. LD / EeCOMPRESSEUNKZ.G” 


#endif 


#ifdef CONFIG_KERNEL_LZO 
#include "../../../../1ib/decompress_unlzo.c" 


#endif 


#ifdef CONFIG_KERNEL_LZ4 
#include "../../../../1ib/decompress_un1z4.c" 


#endif 


在 内 核 解压 之 后 最 后 两 个 函数 是 parse_elf 和 handle_relocations .这 些 函数 的 主要 用 途 是 
把 解压 后 的 内 核 移 动 到 正确 的 位 置 。 事 实 上 ， 解 压 过 程 会 原 地 解压 ， 我 们 还 是 要 把 内 核 移动 
到 正确 的 地 址 。 我 们 已 经 知道 ， 内 核 镜像 是 一 个 ELF 可 执行 文件 ， 所 以 parse_elf 的 主要 目标 
是 移动 可 加 载 的 段 到 正确 的 地 址 。 我 们 可 以 在 readelf 的 输出 看 到 可 加 载 的 段 : 


readelf -1 vmlinux 


Elf file type is EXEC (Executable file) 
Entry point 0x1000000 
There are 5 program headers, starting at offset 64 


Program Headers: 


Type 


LOAD 


LOAD 


LOAD 


LOAD 


Offset 

FileSiz 
0x0000000000200000 
0x0000000000893000 
0x0000000000a93000 
0x000000000016d000 
0x0000000000cC00000 
0x00000000000152d8 
0x0000000000c16000 
0x0000000000138000 


VirtAddr 

MemSiz 

Oxf fFFFFFF81000000 
0x0000000000893000 
Oxffffffff81893000 
0x000000000016d000 
0x0000000000000000 
0x00000000000152d8 
Oxffffffff81a16000 
0x000000000029b000 


PhysAddr 

Flags Align 
0x0000000001000000 
RE 200000 
0x0000000001893000 
RW 200000 
0x0000000001a00000 
RW 200000 
0x0000000001a16000 
RWE 200000 


parse_elf 子 数 的 目标 是 加 载 这 些 段 到 从 choose_random location 函数 得 到 的 output 地 址 。 
这 个 函数 从 检查 ELF 签 名 标志 开始 : 


E1f64_Ehdr ehdr; 
E1f64_Phdr *phdrs, *phdr; 


memcpy(&ehdr, output, sizeof(ehdr)); 


if (ehdr.e_ident[EI_MAGO] != ELFMAGO | | 
ehdr.e_ident[EI_MAG1] != ELFMAG1 | | 
ehdr.e_ident[EI_MAG2] != ELFMAG2 | | 
ehdr.e_ident[EI_MAG3] != ELFMAG3) { 
error("Kernel is not a valid ELF file"); 
return; 


如 果 是 无 效 的 ， 它 会 打印 一 条 错误 消息 并 停机 。 如 果 我 们 得 到 一 个 有 效 的 ELF 文件 ， 我 们 从 
给 定 的 ELF 文件 遍历 所 有 程序 头 ， eerie 所 有 可 加 载 的 段 到 输出 缓冲 区 : 


for (i = 0; i < ehdr.e_phnum; i++) { 
phdr = &phdrs[i]; 


switch (phdr->p_type) { 
case PT_LOAD: 
#ifdef CONFIG_RELOCATABLE 
dest = output; 
dest += (phdr->p_paddr - LOAD_PHYSICAL_ADDR); 


#else 
dest = (void *)(phdr->p_paddr ); 
#endif 
memmove(dest, output + phdr->p_offset, phdr->p_filesz); 
break; 
default: 
break; 
} 
} 


这 就 是 全 部 的 工作 。 
从 现在 开始 ， 所 有 可 加 载 的 段 都 在 正确 的 位 置 。 


在 parse_elf 函数 之 后 是 调用 handle_relocations 函数 。 个 函数 的 实现 依赖 

于 CONFIG X86_NEED_RELOCS 内 核 配 置 选项 ， 如 果 它 被 启用 ， ie ， 只 
有 在 内 核 配 置 时 启 了 coNFIG_RANDOMIZE_BASE 配置 选项 才 会 调用 。 handle_relocations 4 
的 实现 足够 简单 。 这 个 函数 从 基准 内 核 加 载 地 址 的 值 减 掉 LOAD_PHYSICAL ADDR 的 值 ， 从 而 我 


们 获得 内 核 链接 后 要 加 载 的 地 址 和 实际 加 载 地 址 的 差 值 。 在 这 之 后 我 们 可 以 进行 内 核 重 定 
位 ， 因 为 我 们 知道 内 核 加 载 的 实际 地 址 、 它 被 链接 的 运行 的 地 址 和 内 核 镜像 末尾 的 重 定位 
表 。 


在 内 核 重 定位 后 ， 我 们 从 extract_kernel 回来 ， 到 arch/x86/boot/compressed/head_64.S. 


内 核 的 地 址 在 rax 寄存 器 ， 我 们 跳 到 那里 : 


jmp *%rax 


就 是 这 样 。 现 在 我 们 就 在 内 核 里 | 


这 是 关于 内 核 引导 过 程 的 第 五 部 分 的 结尾 。 我 们 不 会 再 看 到 关于 内 核 引 导 的 文章 〈 可 能 有 这 
篇 和 前 面 的 文章 的 更 新 ) ， 但 是 会 有 关于 其 他 内 核 内 部 细节 的 很 多 文章 。 


下 一 章 会 描述 更 高 级 的 关于 内 核 引 导 过 程 的 细节 ， 如 加 载 地 址 随机 化 等 等 。 
如 果 你 有 什么 问题 或 建议 ， 写 个 评论 或 在 twitter 找 我 。 


如 果 你 发 现 文中 描述 有 任何 问题 ， 请 提交 一 个 PR 到 linux-insides-zh ° 


pEi 


e address space layout randomization 
e initrd 

e long mode 

e bzip2 

e RDRand instruction 

e Time Stamp Counter 

e Programmable Interval Timers 

e Previous part 


内 核 初 始 化 流程 


读者 在 这 章 可 以 了 解 到 整个 内 核 初始 化 的 完整 周期 ， 从 内 核 解 压 之 后 的 第 一 步 到 内 核 自身 运 
行 的 第 一 个 进程 。 


注意 这 里 不 是 所 有 内 核 初始 化 步骤 的 介绍 。 这 里 只 有 通用 的 内 核 内 容 ， 不 会 涉及 到 中 断 控 
制 、ACPI 、 以 及 其 它 部 分 。 此 处 没有 详 述 的 部 分 ， 会 在 其 它 章节 中 描述 。 


© 内 核 解压 之 后 的 首要 步骤 - 描述 内 核 中 的 首要 步骤 。 

e 早期 的 中 断 和 异常 控制 - 描述 了 早期 的 中 断 初 始 化 和 早期 的 缺 页 处 理 函 数 。 

e 在 到 达 内 核 入 口 之 前 最 后 的 准备 - 描述 了 在 调用 start_kernel 之 前 最 后 的 准备 工作 。 
e 内 核 入 口 - start_kernel - 描述 了 内 核 通用 代码 中 初始 化 的 第 一 步 。 

e 体系 架构 初始 化 - 描述 了 特定 架构 的 初始 化 。 

© 进一步 初始 化 指定 体系 架构 - 描述 了 再 一 次 的 指定 架构 初始 化 流程 。 

o 最 后 对 指定 体系 架构 初始 化 - 描述 了 指定 架构 初始 化 流程 的 结尾 。 

o 调度 器 初始 化 - 描述 了 调度 初始 化 之 前 的 准备 工作 ， 以 及 调度 初始 化 。 

e RCU 初始 化 - 描述 了 RCU 的 初始 化 。 

e 初始 化 结束 - Linux 内 核 初始 化 的 最 后 部 分 。 


内 核 初 始 化 第 一 部 分 


踏 入 内 核 代 码 的 第 一 步 \TODO: Need 
proofreading ) 


上 一 章 是 引导 过 程 的 最 后 一 部 分 。 从 现在 开始 ， 我 们 将 深入 探究 Linux 内 核 的 初始 化 过 程 。 
在 解压 缩 完 Linux 内 核 镜 像 、 并 把 它 妥 善 地 放 入 内 存 后 ， 内 核 就 开始 工作 了 。 我 们 在 第 一 章 
中 介绍 了 Linux 内 核 引 导 程 序 ， 它 的 任务 就 是 为 执行 内 核 代码 做 准备 。 而 在 本 章 中 ， 我 们 将 
探究 内 核 代 码 ， 看 一 看 内 核 的 初始 化 过 程 一 “ 即 在 启动 PID 为 1 的 init 进程 前 ， 内 核 所 
做 的 大 量 工作 。 


本 章 的 内 容 很 多 ， 介 绍 了 在 内 核 启 动 前 的 所 有 准备 工作 。arch/x86/kernel/head_64.S 文件 中 
定义 了 内 核 入 口 点 ， 我 们 会 从 这 里 开始 ， 和 逐步 地 深入 下 去 。 在 start_kernel BH (定义 在 

init/main.c) 执行 之 前 ， 我 们 会 看 到 很 多 的 初期 的 初始 化 过 程 ， 例 如 初期 页 表 初 始 化 、 切 换 到 
一 个 新 的 内 核 室 间 描述 符 等 等 。 


在 上 一 章 的 最 后 一 节 中 ， 我 们 跟踪 到 了 arch/x86/boot/compressed/head_64.S 文件 中 的 jmp 


指令 : 


jmp *%rax 


此 时 rax 寄存 器 中 保存 的 就 是 Linux 内 核 入 口 点 ， 通 过 调用 decompress_kernel 

(arch/x86/boot/compressed/misc.c) 函数 后 获得 。 由 此 可 见 ， 内 核 引 导 程 序 的 最 后 一 行 代 
码 是 一 名 指向 内 核 入 口 点 的 跳 转 指令 。 既 然 已 经 知道 了 内 核 入 口 点 定义 在 哪 ， 我 们 就 可 以 继 
续 探 完 Linux 内 核 在 引导 结束 后 做 了 些 什 么 。 


内 核 执 行 的 第 一 步 


OK， 在 调用 了 decompress_kernel MAG? rax 寄存 器 中 保存 了 解压 缩 后 的 内 核 镜 像 的 地 
址 ， 并 且 跳 转 了 过 去 。 解 压缩 后 的 内 核 镜 像 的 入 口 点 定义 在 arch/x86/kernel/head 64.S， 这 
个 文件 的 开头 几 行 如 下 : 


__HEAD 

.code64 

.globl startup_64 
startup_64: 


我 们 可 以 看 到 startup_64 过 程 定 义 在 了 _ HEAD RA Po HEAD 只 是 一 个 宏 ， 它 将 展开 
为 可 执行 的 .head.text BA: 


#define _ HEAD .Section "head: text, "ax" 


我 们 可 以 在 arch/x86/kernel/vmlinux.lds.S 链接 器 脚本 文件 中 看 到 这 个 区 段 的 定义 : 


.text : AT(ADDR(.text) - LOAD_OFFSET) { 
_text = .; 


} :text = 0x9090 


除了 对 .text 区 段 的 定义 ， 我 们 还 能 从 这 个 脚本 文件 中 得 知 内 核 的 默认 物理 地 址 与 虚拟 地 
址 。 text 是 一 个 地 址 计数 器 ， 对 于 x86 64 来 说 ， 它 定义 为 : 


» = START_ KERNEL， 


__START_KERNEL 宏 的 定义 在 arch/x86/include/asm/page_types.h 头 文 件 中 ， 它 由 内 核 映 射 的 
虚拟 基 址 与 基 物 理 起 始点 相 加 得 到 : 


#define _START_KERNEL (__START_KERNEL_map + PHYSICAL_START ) 





#define __PHYSICAL_START ALIGN(CONFIG_PHYSICAL_START, CONFIG_PHYSICAL_ALIGN) 


换 名 话说 : 


e Linux 内 核 的 物理 基 址 - ox1000000 ; 
e Linux 内 核 的 虚拟 基 址 - oxffffffff81000000 . 


现在 我 们 知道 了 startup_64 过 程 的 上 默认 物理 地 址 与 虚拟 地 址 ， 但 是 旦 正 的 地 址 必须 要 通过 
下 面 的 代码 计算 得 到 : 


leaq _text(%rip), %rbp 
subq $_text - START_KERNEL_map, %rbp 





没 错 ， 虽 然 定义 为 oxi000000 ， 但 是 仍然 有 可 能 变化 ， 例 如 启用 kASLR 的 时 候 。 所 以 我 们 当 
前 的 目标 是 计算 ox1o00000 与 实际 加 载 地 址 的 差 。 这 里 我 们 首先 将 RIP 相 对 地 址 ( rip- 
relative ) HA rbp 寄存 器 ， 并 且 从 中 减 去 $text - _START_KERNEL_map 。 我 们 已 经 知 
> text 在 编译 后 的 默认 虚拟 地 址 为 Oxffffffff810000006 > 物理 地 址 为 

0x1000000 ° START_KERNEL map 宏 将 展开 为 oxffffffff806066069600 ， 因 此 对 于 对 于 第 二 行 汇 
编 代 码 ， 我 们 将 得 到 如 下 的 表达 式 : 








rbp = 0x1000000 - (Oxffffffff81000000 - 0xffffffff80000000 ) 


在 计算 过 后 rbp 的 值 将 为 o ， 代 表 了 实际 加 载 地 址 与 编译 后 的 默认 地 址 之 间 的 差 值 。 在 
我 们 这 个 例子 中 ，@ RAT Linux 内 核 被 加 载 到 了 默认 地 址 ， 并 且 没 有 启用 kASLR © 


在 得 到 了 startup_64 的 地 址 后 ， 我 们 需要 检查 这 个 地 址 是 否 已 经 正确 对 齐 。 下 面 的 代码 将 


进行 这 项 工作 : 


testl $~PMD_PAGE_MASK, %ebp 
jnz bad_address 


在 这 里 我 们 将 rbp 寄存 器 的 低 32 位 与 pmp_pace_mask 进行 比较 。 PMD_PAGE_MASK 代表 中 层 
页 目录 ( Page middle directory ) 屏蔽 位 (相关 信息 请 阅读 paging 一 节 ) ， 它 的 定义 如 下 : 


#define PMD_PAGE_MASK (~(PMD_PAGE_SIZE-1) ) 
#define PMD_PAGE_SIZE (_AC(1, UL) << PMD_SHIFT) 
#define PMD_SHIFT 21 


可 以 很 容易 得 出 PMD_PAGE_SIZE A 2B 。 在 这 里 我 们 使 用 标准 公式 来 检查 对 齐 问 题 ， 如 果 
text 的 地 址 没有 对 齐 到 2MB ， 则 跳 转 到 bad _ address ° 


在 此 之 后 ， 我 们 通过 检查 高 18 位 来 防止 这 个 地 址 过 大 : 


leaq _text(%rip), %rax 
shrq $MAX_PHYSMEM_BITS, %rax 
jnz bad_address 


这 个 地 址 必须 不 超过 46 个 比特 ， 即 小 于 2 的 46 次 方 : 


#define MAX_PHYSMEM_BITS 46 


OK， 至 此 我 们 完成 了 一 些 初步 的 检查 ， 可 以 继续 进行 后 续 的 工作 了 。 


修正 页 表 基 地 址 


在 开始 设置 Identity 分 页 之 前 ， 我 们 需要 首先 修正 下 面 的 地 址 : 


addq %rbp, early_level4_pgt + (L4_ START_KERNEL*8)(%rip) 
addq %rbp, level3_kernel_pgt + (510*8)(%rip) 
addq %rbp, level3_kernel_pgt + (511%*8)(%rip) 
addq %rbp, level2_fixmap_pgt + (506*8)(%rip) 


如 果 startup_64 的 值 不 为 默认 的 gx16gg666 的 话 ， 则 包括 

early_level4_pgt ` level3_kernel pgt 在 内 的 很 多 地 址 都 会 不 正确 。 rop 寄存 器 中 包含 的 
是 相对 地 址 ， 因 此 我 们 把 它 与 early level4 pgt ` level3_kernel pgt 以 及 
level2_fixmap_pgt 中 特定 的 项 相 加 。 首 先 我 们 来 看 一 下 它们 的 定义 : 


NEXT_PAGE(early_level4_pgt) 
fall 511,8,0 
. quad level3_kernel_pgt - START_KERNEL_map + _PAGE_TABLE 





NEXT_PAGE(level3_kernel_pgt) 
. fill L3_START_KERNEL, 8, 0 
. quad level2_kernel_pgt - START_KERNEL_map + _KERNPG_TABLE 
. quad level2_fixmap_pgt - START_KERNEL_map + _PAGE_TABLE 








NEXT_PAGE(level2_kernel_pgt) 
PMDS(0, PAGE_KERNEL_LARGE_EXEC, 
KERNEL_IMAGE_SIZE/PMD_SIZE) 





NEXT_PAGE(level2_fixmap_pgt) 
F 506,8,0 
. quad leveli_fixmap_pgt - START_KERNEL_map + _PAGE_TABLE 
.fill 5,8,0 





NEXT_PAGE(level1_fixmap_pgt) 
artali 512,8,0 


看 起 来 很 难 理解 ， 实 则 不 然 。 首 先 我 们 来 看 一 下 early_levela pgt 。 它 的 前 (4096 - 8) 个 字 
PAA 96， 即 它 的 前 511 个 项 均 不 使 用 ， 之 后 的 一 项 是 level3 _ kernel pgt - 

START_KERNEL_map + _PAGE_TABLE 。 我 们 知道 START_KERNEL_map 是 内 核 的 虚拟 基地 址 ， 
此 减 去 START_KERNEL map 后 就 得 到 了 1level3_kernel_pgt 的 物理 地 址 。 现 在 我 们 来 看 一 下 
_PAGE_TABLE ， 它 是 页 表 项 的 访问 权限 : 











#define _PAGE_TABLE (_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | \ 
_PAGE_ACCESSED | _PAGE_DIRTY) 





更 多 信息 请 阅读 分 页 部 分 . 


level3_kernel_pgt 中 保存 的 两 项 用 来 映射 内 核 空 间 ， 在 它 的 前 516 (PP 

L3_START_KERNEL ) 项 均 为 © 。 这 里 的 L3_START_KERNEL 保存 的 是 在 上 层 页 目录 (Page 
Upper Directory) 中 包含 _sTART_KERNEL map 地 址 的 那 一 条 索引 ， 它 等 于 510 。 后 面 一 项 
level2 kernel pgt - START KERNEL map + _KERNPG_TABLE 中 的 level2 kernel pgt 比较 容易 
理解 ， 它 是 一 条 页 表 项 ， 包 含 了 指向 中 层 页 目录 的 指针 ， 它 用 来 映射 内 核 空 间 ， 并 且 具 有 如 
下 的 访问 权限 : 











#define _KERNPG_TABLE (_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | \ 
_PAGE_DIRTY) 


level2_fixmap_pgt 是 一 系列 虚拟 地 址 ， 它 们 可 以 在 内 核 空 间 中 指向 任意 的 物理 地 址 。 它 们 
由 level2_fixmap_pgt 4FAAT A> 10 MB 大 小 的 空间 用 来 为 vsyscalls 做 映 
射 。 level2 kernel pgt 则 调用 了 poms Æ > Æ __START_KERNEL_map 地 址 处 为 内 核 的 .text 
创建 了 512 MB 大 小 的 空间 (这 512 MB 空间 的 后 面 是 模块 内 存 空 间 ) © 





现在 ， 在 看 过 了 这 些 符 号 的 定义 之 后 ， 让 我 们 回 到 本 节 开 始 时 介绍 的 那 几 行 代码 。 rbp 寄存 
器 包含 了 实际 地 址 与 startup_64 地 址 之 差 ， 其 中 startup 64 的 地 址 是 在 内 核 链接 时 获得 

的 。 因 此 我 们 只 需要 把 它 与 各 个 页 表 项 的 基地 址 相 加 ， 就 能 够 得 到 正确 的 地 址 了 。 在 这 里 这 

些 操作 如 下 : 


addq %rbp, early_level4_pgt + (L4_START_KERNEL*8) (%rip) 
addq %rbp, level3_kernel_pgt + (510*8)(%rip) 
addq %rbp, level3_kernel_pgt + (511%*8)(%rip) 
addq %rbp, level2_fixmap_pgt + (506*8)(%rip) 


换 句 话说 ， early_level4_pgt 的 最 后 一 项 就 是 level3_kernel_pgt °’ level3_kernel_pgt 的 
最 后 两 项 分 别 是 level2 kernel pgt 和 level2_fixmap_pgt ° level2_fixmap_pgt 的 第 507 项 
就 是 leveli1_fixmap_pgt NA Re 


在 这 之 后 我 们 就 得 到 了 : 


early_level4_pgt[511] -> level3_kernel_pgt[0] 
level3_kernel_pgt[510] -> level2_kernel_pgt[0] 
level3_kernel_pgt[511] -> level2_fixmap_pgt[0] 
level2_kernel_pgt[0] -> 512 MB kernel mapping 
level2_fixmap_pgt[507] -> leveli_fixmap_pgt 


a AREN E ANSER 
卉 充 这些 页 目录 结构 的 时 候 修正 。 我 们 修正 了 页 表 基地 址 后 ， 就 可 以 开始 构造 这 些 页 目录 
了 。 


Identity Map Paging 


现在 我 们 可 以 进入 到 对 初期 页 表 进行 Identity 映射 的 初始 化 过 程 了 。 在 Identity 映射 分 页 中 ， 
虚拟 地 址 会 被 映射 到 地 址 相同 的 物理 地 址 上 ， 即 1 : 1 。 下 面 我 们 来 看 一 下 细节 。 首 先 我 们 
找到 _text 与 _early level4 pgt 的 RIP 相对 地 址 ， 并 把 他 们 放 入 rdi 与 rox 寄存 器 
中 。 





leaq _text(%rip), %rdi 
leaq early_level4_pgt(%rip), %rbx 


在 此 之 后 我 们 使 用 rax 保存 text 的 地 址 。 同 时 ， 在 全 局 页 目录 表 中 有 一 条 记录 中 存放 的 
是 text 的 地 址 。 为 了 得 到 这 条 索引 ， 我 们 把 _text 的 地 址 右 移 PGDIR_SHIFT 位 。 


movd %rdi, %rax 
shrq $PGDIR_SHIFT, %rax 


leaq (4096 + _KERNPG_TABLE)(%rbx), %rdx 
movq %rdx, O(%rbx, %rax, 8) 
movq %rdx, 8(%rbx,%rax,8) 


其 中 PGDIR SHIFT A 39 ° PGDIR SHIFT 表示 的 是 在 虚拟 地 址 下 的 全 局 页 目录 位 的 屏蔽 值 
(mask) 。 下 面 的 宏 定 义 了 所 有 类 型 的 页 目录 的 屏蔽 值 : 


#define PGDIR_SHIFT 39 
#define PUD_SHIFT 30 
#define PMD_SHIFT 21 


此 后 我 们 就 将 level3_kernel pgt 的 地 址 放 进 rdx 中 ， 并 将 它 的 访问 权限 设置 为 
_KERNPG_TABLE ( RE) ， 然 后 将 level3_kernel_pgt HA early_level4_pgt 的 两 项 中 2 
后 我 们 给 rdx 寄存 器 加 上 4096 (FP early level4 pgt 的 大 小 ) ， 并 把 rdi 寄存 器 的 


值 ( 即 _text 的 物理 地 址 ) 赋值 给 rax 寄存 器 。 之 后 我 们 把 上 层 页 目录 中 的 两 个 项 写 入 
level3_kernel_pgt 


addq $4096, %rdx 

movq %rdi, %rax 

shrq $PUD_SHIFT, %rax 

andl $(PTRS_PER_PUD-1), %eax 
movq %rdx, 4096(%rbx, %rax, 8) 
incl %eax 

andl $(PTRS_PER_PUD-1), %eax 
movd %rdx, 4096(%rbx, %rax, 8) 


下 一 步 我 们 把 中 层 页 目录 表 项 的 地 址 写 入 level2_kernel_pgt ， 然 后 修正 内 核 的 text 和 data 
的 虚拟 地 址 : 


leaq level2_kernel_pgt(%rip), %rdi 
leaq 4096(%rdi), %r8 


alts testq $1, O(%rdi) 
jz 2f 
addq %rbp, O(%rdi) 
2: addq $8, %rdi 


cmp %r8, %rdi 
jne 1b 


这 里 首先 把 level2_kernel pgt 的 地 址 赋值 给 rdi ， 并 把 页 表 项 的 地 址 赋值 给 r8 FF 
器 。 下 一 步 我 们 来 检查 level2_kernel pgt 中 的 存在 位 ， 如 果 其 为 0， 就 把 rdi 加 上 8 以 便 
指向 下 一 个 页 。 然 后 我 们 将 其 与 re ( 即 页 表 项 的 地 址 ) 作 比 较 ， 不 相等 的 话 就 跳 转 回 前 面 
的 标签 1 ， 反 之 则 继续 运行 。 


接 下 来 我 们 使 用 rbp (FP _text 的 物理 地 址 ) 来 修正 phys_base 物理 地 址 。 将 
early_level4_pgt 的 物理 地 址 与 rbp 相 加 ， 然 后 跳 转 至 标签 1 


addq %rbp, phys_base(%rip) 
movq $(early_level4 pgt - START_KERNEL_map), %rax 
jmp 1f 





其 中 phys_base 与 level2_kernel_pgt 第 一 项 相同 > 为 512 MB 的 内 核 映 射 。 


跳 转 至 内 核 入 口 点 之 前 的 最 后 准备 


此 后 我 们 就 跳 转 至 标签 1 来 开启 PAE 和 pce (Paging Global Extension) ， 并 且 
将 phys_base 的 物理 地 址 ( 见 上 ) HA rax 就 寄存 器 ， 同 时 将 其 放 入 crs FRB: 


movl $(X86_CR4_PAE | X86_CR4_PGE), %ecx 
movq %rcx, %cr4 


addq phys_base(%rip), %rax 
movq %rax, %cr3 


接 下 来 我 们 检查 CPU 是 否 支 持 NX 位 : 


movl $0x80000001, %eax 
cpuid 
movl %edx,%edi 


首先 将 oxgoooo001 放 入 eax 中 ， 然 后 执行 cpuid 指令 来 得 到 处 理 器 信息 。 这 条 指令 的 结 
果 会 存放 在 edx 中 ， 我 们 把 他 再 放 到 edi 里 。 


现在 我 们 把 MSR EFER (FP oxcoooooso ) 放 入 ecx ， 然 后 执行 rdmsr 指令 来 读 取 CPU 中 
的 Model Specific Register (MSR) ° 


movl $MSR_EFER, %ecx 
rdmsr 


返回 结果 将 存放 于 edx:eax 。 下 面 展 示 了 EFER 各 个 位 的 含义 : 


31 16 15 14 13 12 11 10 9 87 1 0 

| | 7 | | | (sen eile pli ea | 

| Reserved MBZ | C | FFXSR | LMSLE |SVME|NXE|LMA|MBZ|LME|RAZ|SCE| 

| | E | | | [| 
在 这 里 我 们 不 会 介绍 每 一 个 位 的 含义 ， 没 有 涉及 到 的 位 和 其 他 的 MSR 将 会 在 专门 的 部 分 介 


绍 。 在 我 们 将 EFER TEA edx:eax 之 后 ， 通 过 btsl 来 将 EFER_ScE (PP ROM) 置 1， 设 
置 sce 位 将 会 启用 syscall 以 及 SYSRET 指令 。 下 一 步 我 们 检查 edi (PP cpuid 的 结果 
(WE) ) 中 的 第 20 位 。 如 果 第 20 位 (BP Nx 位 ) 置 位 ， 我 们 就 只 把 EFER_SCE FA 
MSR ° 


btsl $_EFER_SCE, %eax 

btl $20, %edi 

jnc 1f 

btsl $ EFER_NX, %eax 

btsq $_PAGE_BIT_NX, early_pmd_flags(%rip) 


如 果 支 持 NX 那么 我 们 就 把 _EFER_NX MGR o 在 设置 了 NX 后， 还 要 对 cro 
(control register) 中 的 一 些 位 进行 设置 : 


© xs6_cro PE -系统 处 于 保护 模式 ; 

e X86_CRO MP - 与 CR0 的 TS 标志 位 一 同 控制 WAIT/FWAIT 指令 的 功能 ; 

© xX86_CRO_ET - 386 人 允许 指定 外 部 数学 协 处理 器 为 80287 或 80387; 

© X86_CRO NE - 如果 置 位 ， 则 启用 内 置 的 x87 浮 点 错误 报告 ， 否 则 启用 PC 风格 的 x87 错 误 检 
M] ; 

© X86_CRO WP - 如 果 置 位 ， 则 CPU 在 特权 等 级 为 0 时 无 法 写 入 只 读 内 存 页 ; 

e X86_CRO_AM - 当 AM 位 置 位 、EFLGS 中 的 AC 位 置 位 、 特 权 等 级 为 3 时 ， 进 行 对 齐 检查 ; 

© X86_CRO_PG -启用 分 页 


#define CRO_STATE (X86_CRO_PE | X86 CRO _MP | X86_CRO_ET | \ 
X86_CRO_NE | X86_ CRO WP | X86_ CRO AM | \ 


X86_CRO_PG) 
movl $CRO_STATE, %eax 
movq %rax, %cro 


为 了 从 汇编 执行 C 语 言 代码 ， 我 们 需要 建立 一 个 栈 。 首 先 将 栈 指针 指向 一 个 内 存 中 合适 的 区 
域 ， 然 后 重 置 FLAGS 寄 存 器 


movq stack_start(%rip), %rsp 
pushq $0 
popfq 


在 这 里 最 有 意思 的 地 方 在 于 stack_start 。 它 也 定义 在 当前 的 源 文件 中 : 


GLOBAL(stack_start) 
.quad init_thread_union+THREAD_SIZE-8 


对 于 GLOABL 我 们 应 该 很 熟悉 了 。 它 在 arch/x86/include/asmilinkage.h 头 文件 中 定义 如 下 : 


#define GLOBAL(name) \ 
.globl name; \ 
name: 


THREAD_SIZE 定义 在 arch/x86/include/asm/page 64 types.h， 它 依赖 于 KASAN_STACK_ORDER 
的 值 : 


#define THREAD_SIZE_ORDER (2 + KASAN_STACK_ORDER) 
#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER) 


首先 来 考虑 当 禁 用 了 kasan 并 且 PAGE_SIZE 大 小 为 4096 时 的 情况 。 此 时 THREAD_SIZE 将 为 
16 KB， 代 表 了 一 个 线程 的 栈 的 大 小 。 为 什么 是 线程 ? 我 们 知道 每 一 个 进程 可 能 会 有 父 进程 
和 子 进 程 。 事 实 上 ， 父 进程 和 子 进程 使 用 不 同 的 栈 空间 ， 每 一 个 新 进程 都 会 拥有 一 个 新 的 内 
核 栈 。 在 Linux 内 核 中 ， 这 个 栈 由 thread_info 结构 中 的 一 个 union 表 示 : 


union thread_union { 
struct thread_info thread_info; 
unsigned long stack[THREAD_SIZE/sizeof(long)]; 


}; 


例如 ， init_thread_union 定义 如 下 : 


union thread_union init_thread_union init_task_data = 
{ INIT_THREAD_INFO(init_task) }; 





其 中 INIT THREAD INFO 接受 task struct 结构 类 型 的 参数 ， 并 进行 一 些 初 始 化 操作 : 


#define INIT_THREAD_INFO(tsk) \ 
{ \ 
. task = &tsk, \ 
. flags = 0, \ 
.Cpu = 0, \ 
.addr_limit = KERNEL_DS, \ 
} 


task_struct 结构 在 内 核 中 代表 了 对 进程 的 描述 o。 因 此， thread_union 包含 了 关于 一 个 进程 
的 低级 信息 ， 并 且 其 位 于 进程 栈 底 : 


| | 
| | 
| | 
| Kernel stack | 
| | 
| | 
| | 


需要 注意 的 是 我 们 在 栈 顶 保留 了 8 个 字 节 的 空间 ， 用 来 保护 对 下 一 个 内 存 页 的 非法 访问 。 


在 初期 启动 栈 设 置 好 之 后 ， 使 用 igt 指令 来 更 新 全 局 描述 符 表 : 


lgdt early_gdt_descr(%rip) 


其 中 early_gdt_descr 定义 如 下 : 


early_gdt_descr: 

.word GDT_ENTRIES*8-1 
early_gdt_descr_base: 

. quad INIT_PER_CPU_VAR(gdt_page) 


需要 重新 加 载 全 局 描述 附 表 的 原因 是 ， 虽 然 目 前 内 核 工作 在 用 户 空间 的 低地 址 中 ， 但 很 快 内 
anes 在 它 自己 的 内 存 地 址 空间 中 和 运行。 下 面 让 我 们 来 看 一 下 early_gdt_descr 的 定义 。 全 
兽 述 符 表 和 包含 了 32 项 ， 用 于 内 核 代码 、 数 据 、 线 程 局 部 存储 段 等 


#define GDT_ENTRIES 32 


现在 来 看 一 下 early gdt_descr_base . 首先 ， gdt_page 的 定义 
在 arch/x86/include/asm/desc.h 中 : 


struct gdt_page { 
struct desc_struct gdt[GDT_ENTRIES]; 
} __attribute_ _((aligned(PAGE_SIZE))); 


它 只 包含 了 一 项 desc_struct 的 数组 gdt 。 desc_struct 定义 如 下 : 


struct desc_struct { 


union { 
struct { 
unsigned int a; 
unsigned int b; 
J; 
struct { 
u16 limit0; 
u16 base; 
unsigned basel: 8, type: 4, s: 1, dpl: 2, p: 1; 
unsigned limit: 4, avl: 1, 1: 1, d: 1, g: 1, base2: 8; 
J; 
}; 


} __attribute__((packed)); 


它 跟 oot 描述 符 的 定义 很 像 。 同 时 需要 注意 的 是 ， gdt_page 结构 是 PAGE_SIZE ( 4096 ) 对 
齐 的 ， 即 gdt 将 会 占用 一 页 内 存 。 


下 面 我 们 来 看 一 下 INIT_PER CPU_VAR ， 它 定义 在 arch/x86/include/asm/percpu.h， 只 是 将 给 
定 的 参数 与 init_per_cpu__ 连接 起 来 : 


#define INIT_PER_CPU_VAR(var) init_per_cpu__##var 


所 以 在 宏 展 开 之 后 ， 我 们 会 得 到 init_per_cpu__gdt_page ° mÆ linker script 中 可 以 发 现 : 





#define INIT_PER_CPU(x) init_per_cpu__##x = x + __per_cpu_load 
INIT_PER_CPU(gdt_page) ; 


INIT_PER_cPU 扩展 后 也 将 得 到 init_per_cpu_gdt_page 并 将 它 的 值 设 置 为 相对 于 
__per_cpu_load 的 偏 移 量 。 这 样 ， 我 们 就 得 到 了 新 GDT 的 正确 的 基地 址 。 





per-CPU 变 量 是 2.6 内 核 中 的 特性 。 顾 名 思 义 ， 当 我 们 创建 一 个 per-cpU 变量 时 ， 每 个 CPU 
都 会 拥有 一 份 它 自己 的 拷贝 ， 在 这 里 我 们 创建 的 是 gdt_page per-CPU 变 量 。 这 种 类 型 的 变量 
有 很 多 有 点 ， 比 如 由 于 每 个 CPU 都 只 访问 自己 的 变量 而 不 需要 锁 等 。 因 此 在 多 处 理 器 的 情况 
下 ， 每 一 个 处 理 器 核心 都 将 拥有 一 份 自己 的 ot 表 ， 其 中 的 每 一 项 都 代表 了 一 块 内 存 ， 这 块 
内 存 可 以 由 在 这 个 核心 上 运行 的 线程 访问 。 这 里 Concepts/per-cpu 有 关于 per-cpeu 变量 的 
更 详细 的 介绍 。 


在 加 载 好 了 新 的 全 局 描述 附 表 之 后 ， 跟 之 前 一 样 我 们 重新 加 载 一 下 各 个 段 : 


xorl %eax, %eax 
movl %eax, %dS 
movl %eax,%SS 
movl %eax,%es 
movl %eax,%fs 
movl %eax,%gs 


在 所 有 这 些 步骤 都 结束 后 ， 我 们 需要 设置 一 下 gs 寄存 器 ， 令 它 指向 一 个 特殊 的 栈 
irqstack ， 用 于 处 理 中 断 


movl $MSR_GS_ BASE, %ecx 


movl initial_gs(%rip),%eax 
movl initial_gs+4(%rip),%edx 
wrmsr 


其 中 ， MSR_GS_BASE 为 : 


#define MSR_GS_BASE 0xc0000101 


我 们 需要 把 MSR_GS_BASE BA ecx 寄存 器 ， 同 时 利用 wrmsr 指令 向 eax 和 edx 处 的 地 
址 加 载 数 据 ( 即 指向 initial gs ) ° cs, fs, ds 和 ss 段 寄存 器 在 64 位 模式 下 不 用 来 寻 
址 ， 但 fs 和 gs 可 以 使 用 。 fs 和 gs 有 一 个 隐 含 的 部 分 (与 实 模 式 下 的 cs 段 寄 存 器 
类 似 ) ， 这 个 隐 含 部 分 存储 了 一 个 描述 符 ， 其 指向 Model Specific Registers。 因 此 上 面 的 
oxc0000101 是 一 个 gs.base MSR 地 址 。 当 发 生 系统 调用 或 者 中 断 时 ， 入 口 点 处 并 没有 内 
核 栈 ， 因 此 MSR_GS_BASE 将 会 用 来 存放 中 断 栈 。 


ETRE 模式 中 的 bootparam 结构 的 地 址 放 入 rdi (要 记得 rsi 从 一 开始 就 保存 了 
这 个 结构 体 的 指针 )， 然 后 跳 转 到 C 语 言 代码 : 


movq initial_code(%rip),%rax 
pushq $0 

pushq $__ KERNEL_CS 

pushq %r ax 

lretq 


这 里 我 们 把 initial code MA rax 中 ， 并 且 向 栈 里 分 别 压 入 一 个 无 用 的 地 
址 、 __KERNEL_CS 和 initial_code 的 地 址 。 随 后 的 lreq 指令 表示 从 栈 上 弹出 返 回 地 址 并 
跳 转 。 initial code 同样 定义 在 这 个 文件 里 : 


.balign 8 
GLOBAL (initial_code) 
. quad x86_64_start_kernel 


可 以 看 到 initial code 包含 了 x86 64 start_kernel 的 地 址 ， 其 定义 在 
arch/x86/kerne/head64.c : 


asmlinkage _ visible void _ init x86 64 start_kernel(char * real_mode data) { 


这 个 函数 接受 一 个 参数 real mode data 《刚才 我 们 把 实 模式 下 数据 的 地 址 保存 到 了 rdi 寄 
ARP) 


这 个 函数 是 内 核 中 第 一 个 执行 的 C 语 言 代码 ! 


走 进 start_kernel 


在 我 们 真正 到 达 “ 内 核 入 口 点 ”-init/main.c 中 的 start_kernel 亟 数 之 前 ， 我 们 还 需要 最 后 的 准备 工 
作 : 


首先 在 x86 64_start_kernel 函数 中 可 以 看 到 一 些 检 查 工 作 : 


BUILD_BUG_ON(MODULES_VADDR < START_KERNEL_map); 

BUILD_BUG_ON(MODULES_VADDR - START_KERNEL_map < KERNEL_IMAGE_SIZE); 
BUILD_BUG_ON(MODULES_LEN + KERNEL_IMAGE_SIZE > 2*PUD_SIZE); 
BUILD_BUG_ON((__START_KERNEL_map & ~PMD_MASK) != 0); 

BUILD_BUG_ON( (MODULES _VADDR & ~PMD_MASK) != 0); 

BUILD_BUG_ON(! (MODULES _VADDR > __START_KERNEL)); 

BUILD_BUG_ON(!(((MODULES_END - 1) & PGDIR_MASK) == (__START_KERNEL & PGDIR_MASK))); 
BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= MODULES_END); 

















这 些 检查 包括 : 模块 的 虚拟 地 址 不 能 低 于 内 核 text 段 基 地 址 _ START_KERNEL_map ， 包 含 模块 
的 内 核 text 段 的 空间 大 小 不 能 小 于 内 核 镜 像 大 小 等 等 。 BUILD Buon 宏 定义 如 下 : 


#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)])) 


我 们 来 理解 一 下 这 些 巧 妙 的 设计 是 怎么 工作 的 。 首 先 以 第 一 个 条 件 MopuLES_VADDR < 
START_KERNEL_map 为 例 : !1conditions 等 价 于 condition != 0 ， 这 代表 如 果 





MODULES_VADDR < __START_KERNEL_map Aik? W] 11(condition) 为 1， 否则 为 0。 执行 2*11 
(condition) 之 后 数值 变 为 2 或 o 。 因 此 ， 这 个 宏 执 行 完 后 可 能 产生 两 种 不 同 的 行为 : 





e 编译 错误 。 因 为 我 们 尝试 取 获 取 一 个 字符 数组 索引 为 负数 的 变量 的 大 小 。 
© 没有 编译 错误 。 


就 是 这 么 简单 ， C 语 言 中 某 些 常量 导致 编译 错误 的 技巧 实现 了 这 一 设计 。 


接 下 来 start_kernel 调用 了 cr4_init_shadow 函数 ， 其 中 存储 了 每 个 CPU 中 cra 的 Shadow 
Copy。 上 下 文 切换 可 能 会 修改 cra 中 的 位 ， 因 此 需要 保存 每 个 CPU 中 cra 的 内 容 。 在 这 
之 后 将 会 调用 reset_early_page_tables He? CHAT 所 有 的 全 局 页 目录 项 ， 同 时 向 cr3 
中 重新 写 入 了 的 全 局 页 目录 表 的 地 址 : 


for (i = 0; i < PTRS_PER_PGD-1; i++) 
early_level4_pgt[i].pgd = 0; 


next_early_pgt = 0; 


write_cr3(__pa_nodebug(early_level4_pgt)); 


很 快 我 们 就 会 设置 新 的 页 表 。 在 这 里 我 们 遍历 了 所 有 的 全 局 页 目录 项 (其 中 PTRS_PER_PGD A 
512 ) ， 将 其 设置 为 0。 之 后 将 next_early_pgt 设置 为 0 (会 在 下 一 篇 文章 中 介绍 细节 ) > 
同时 把 early_level4_pgt 的 物理 地 址 写 入 cr3 ° _panodebuy 是 一 个 宏 ， 将 被 扩展 为 : 


((unsigned long)(x) - START_KERNEL_map + phys_base) 





此 后 我 们 清空 了 从 bss _ stop 到 _bss start 的 _bss 段 ， 下 一 步 将 是 建立 初期 IDT (中 断 
描述 符 表 ) ”的 处 理 代码 ， 内 容 很 多 ， 我 们 将 会 留 到 下 一 个 部 分 再 来 探究 。 


Í ti 
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第 一 部 分 关于 Linux 内 核 的 初始 化 过 程 到 这 里 就 结束 了 。 


如 果 你 有 任何 问题 或 建议 ， 请 在 twitter 上 联系 我 0xXAX， 或 者 通过 邮件 与 我 沟通 ， 还 可 以 新 
J issue ° 


下 一 部 分 我 们 会 看 到 初期 中 断 处 理 程序 的 初始 化 过 程 、 内 核 空 间 的 内 存 映射 等 


相关 链接 


内 核 解 压 之 后 的 首要 步骤 


Model Specific Register 

e Paging 

e Previous part - Kernel decompression 
e NX 

ASLR 
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内 核 初始 化 第 二 部 分 


初期 中 断 和 异种 处 理 


在 上 一 个 部 分 我 们 谈 到 了 初期 中 断 初始 化 。 目 前 我 们 已 经 处 于 解压 缩 后 的 Linux 内 核 中 了 ， 
还 有 了 用 于 初期 启动 的 基本 的 分 页 机 制 。 我 们 的 目标 是 在 内 核 的 主体 代码 执行 前 做 好 准备 工 
作 。 


我 们 已 经 在 AE 的 第 一 部 分 做 了 一 些 工 作 ， 在 这 一 部 分 中 我 们 会 继续 分 析 关 于 中 断 和 异常 
处 理 部 分 的 代码 。 


我 们 在 上 一 部 分 谈 到 了 下 面 这 个 循环 : 


for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) 
set_intr_gate(i, early_idt_handler_array[i]); 


这 段 代码 位 于 arch/x86/kernelhead64.c。 在 分 析 这 段 代 码 之 前 ， 我 们 先 来 了 解 一 些 关 于 中 断 
和 中 断 处 理 程序 的 知识 。 


FE 


中 断 是 一 种 由 软件 或 硬件 产生 的 、 向 CPU 发 出 的 事件 。 例 如 ， 如 果 用 户 按 下 了 键盘 上 的 一 个 
按键 时 ， 就 会 产生 中 断 。 此 时 CPU 将 会 暂停 当前 的 任务 ， 并 且 将 控制 流转 到 特殊 的 程序 中 
一 一 中 断 处 理 程序 (Interrupt Handler)。 一 个 中 断 处 理 程序 会 对 中 断 进行 处 理 ， 然 后 将 控制 权 
交还 给 之 前 暂停 的 任务 中 。 中 断 分 为 三 类 : 


。 软件 中 断 - 当 一 个 软件 可 以 向 CPU 发 出 信号 ， 表 明 它 需要 系统 内 核 的 相关 功能 时 产生 。 
这 些 中 断 通 常用 于 系统 调用 ; 

。 硬件 中 断 - 当 一 个 硬件 有 任何 事件 发 生 时 产生 ， 例 如 键盘 的 按键 被 按 下 ; 

。 异常 - 当 CPU 检 测 到 错误 时 产生 ， 例 如 发 生 了 除 零 错误 或 者 访问 了 一 个 不 存在 的 内 存 
页 。 


每 一 个 中 断 和 异常 都 可 以 由 一 个 数 来 表示 ， 这 个 数 叫 做 向 量 号 ， 它 可 以 取 从 o 到 255 中 
的 任何 一 个 数 。 通 常 在 实践 中 前 32 个 向 量 号 用 来 表示 异常 ， 32 到 255 用 来 表示 用 户 定 
义 的 中 断 。 可 以 看 到 在 上 面 的 代码 中 ， NUM_EXCEPTION_VECTORS 就 定义 为 : 


#define NUM_EXCEPTION_VECTORS 32 


CPU 会 从 APIC 或 者 CPU 引 脚 接收 中 断 ， 并 使 用 中 断 向 量 号 作为 ”中 断 描述 符 表 的 索引 。 下 面 
的 表 中 列 出 了 0-31 号 异常 : 


| Vector |Mnemonic |Description |Type |Error Code|Source 
19 | #DE |Divide Error |Fault |NO |DIV and IDIV 

| 
| 本 
I1 | #DB |Reserved IF/T |NO 

| 
| 
|2 | --- | NMI IINT |NO Jexternal NMI 

| 
| 本 
|3 | #BP |Breakpoint |Trap |NO |INT 3 

| 
[相生 
| 4 | #0F | Overflow |Trap |NO JINTO instruction 

| 
| 
15 | #BR |Bound Range Exceeded |Fault |NO |BOUND instruction 

| 
本 
|6 | #UD |Invalid Opcode |Fault |NO 1UD2 instruction 

| 
| 
|7 | #NM |Device Not Available|Fault|NO |Floating point or [F]WAIT 

| 
[本 
|8 | #DF |Double Fault | Abort | YES |Ant instrctions which can gener 
ate NMI| 
| 本 
|9 | --- |Reserved | Fault |NO 


| 10 | #TS |Invalid TSS |Fault|YES |Task switch or TSS access 


|11 | #NP |Segment Not Present |Fault |NO |Accessing segment register 


|12 | #SS |Stack-Segment Fault |Fault|YES |Stack operations 

| 
| Ae Ano anae ORA ono AGRONA ARoS o Anan ODRA AnS opo R DDH AOE onas 
|13 | #GP |General Protection |Fault|YES |Memory reference 

| 
| 本 有 
|14 | #PF |Page fault | Fault | YES |Memory reference 

| 
| 
|15 | --- |Reserved | NO 

| 
| eraann o po RoR Taaa AOAR Oo Sao aAph PONA eoa o onn Rie CoR 
|16 | #MF |x87 FPU fp error | Fault |NO |Floating point or [F]Wait 

| 
| 
|17 | #AC |Alignment Check |Fault|YES |Data reference 

| 
[本 
|18 | #MC |Machine Check | Abort |NO 

| 
| ae en n a Ao ea o oo i apao noS prO Oori 
|19 | #XM |SIMD fp exception | Fault |NO |SSE[2,3] instructions 

| 
| 
|20 | #VE |Virtualization exc. |Fault |NO |EPT violations 

| 
和 
121-31 | --- |Reserved |INT |NO JExternal interrupts 


为 了 能 够 对 中 断 进行 处 理 ，CPU 使 用 了 一 种 特殊 的 结构 - 中 断 描述 符 表 (IDT) ° IDT 是 一 个 
由 描述 符 组 成 的 数组 ， 其 中 每 个 描述 符 都 为 8 个 字 节 ， 与 全 局 描述 附 表 一 致 ; 不 过 不 同 的 是 ， 
我 们 把 DT 中 的 每 一 项 叫做 门 (gate) 。 为 了 获得 某 一 项 描述 符 的 起 始 地 址 ，CPU 会 把 向 量 号 


乘 以 8， 在 64 位 模式 中 则 会 乘 以 16。 在 前 面 我 们 已 经 见 过 ，CPU 使 用 一 个 特殊 的 GDTR 寄存 
器 来 存放 全 局 描述 符 表 的 地 址 ， 中 断 描述 符 表 也 有 一 个 类 似 的 寄存 器 IDTR ， 同 时 还 有 用 于 
将 基地 址 加 载 入 这 个 寄存 器 的 指令 lidt ° 


64 位 模式 下 IDT 的 每 一 项 的 结构 如 下 : 


63 48 47 46 44 42 39 34 32 
| | le d | le | 
| Offset 31. .16 | P | P | © |Type [© 0 0 | © | © | IST | 
| | LE A | [| | 
31 15 16 0 
| | | 
| Segment Selector | Offset 15..0 | 


其 中 : 


© offset - 代表 了 到 中 断 处 理 程序 入 口 点 的 偏 移 ; 

e DPL - 描述 符 特 权 级 别 ; 

e p - Segment Present 标志 ; 

e Segment selector - 在 GDT 或 LDT 中 的 代码 段 选择 子 ; 
e IST -用 来 为 中 断 处 理 提供 一 个 新 的 栈 。 


最 后 的 Type 域 描 述 了 这 一 项 的 类 型 ， 中 断 处 理 程序 共 分 为 三 种 : 

o 任务 描述 符 

。 中 断 描 述 符 

。 陷阱 描述 符 

中 断 和 陷阱 描述 符 包含 了 一 个 指向 中 上 断 处 理 程序 的 远 (far) 指针 ， 二 者 唯一 的 不 同 在 于 CPU 处 


理 IF 标志 的 方式 。 如 果 是 由 中 断 门 进 入 中 断 处 理 程 序 的 ，CPU 会 清除 IF 标志 位 ， 这 样 
当当 前 中 断 处 理 程序 执行 时 ，CPU 不 会 对 其 他 的 中 断 进 行 处 理 ; 只 有 当当 前 的 中 断 处 理 程序 


返回 时 ，CPU 才 在 iret 指令 执行 时 重新 设置 IF 标志 位 。 

中 断 门 的 其 他 位 为 保留 位 ， 必 须 为 0。 下 面 我 们 来 看 一 下 CPU 是 如 何 处 理 中 断 的 : 
© CPU 会 在 栈 上 保存 标志 寄存 器 、 cs 段 寄存 器 和 程序 计数 器 IP ; 
e 如 果 中 断 是 由 错误 码 引 起 的 (比如 #pF ) ，CPU 会 在 栈 上 保存 错误 码 ; 
© 在 中 断 处 理 程序 执行 完毕 后 ， 由 iret 指令 返回 。 


OK ， 接 下 来 我 们 继续 分 析 代 码 。 


设置 并 加 载 IDT 
我 们 分 析 到 了 如 下 代码 : 


for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) 
set_intr_gate(i, early_idt_handler_array[i]); 


这 里 循环 内 部 调用 了 set_intr_gate ， 它 接受 两 个 参数 : 


。 中 断 号 ， 即 wee 5 
o 中 断 处 理 程序 的 地 址 。 
同时 ， 这 个 函数 还 会 将 中 断 门 插 入 至 wr 表 中 ， 代 码 中 的 &idt_descr 数组 即 为 IDT ° 首 


先 让 我 们 来 看 一 下 early_idt_handler_array 数组 ， 它 定义 在 
arch/x86/include/asm/segment.h 头 文件 中 ， 包 含 了 前 32 个 异常 处 理 程序 的 地 址 : 


#define EARLY_IDT_HANDLER_SIZE 9 
#define NUM_EXCEPTION_VECTORS 32 


extern const char early_idt_handler_array[NUM_EXCEPTION_VECTORS ] [EARLY_IDT_HANDLER_SIZ 


E]; 


early_idt_handler_array 是 一 个 大 小 为 ”288 字 节 的 数组 ， 每 一 项 为 9 个 字 节 ， 其 中 2 个 字 
节 的 备用 指令 用 于 向 栈 中 压 入 默认 错误 码 (如 果 异 常 本 身 没 有 提供 错误 码 的 话 ) ，2 个 字 节 的 
负 令 用 于 向 栈 中 压 入 向 量 号 ， 剩 余 5 个 字 节 用 于 跳 转 到 弄 常 处 理 程序 。 


在 上 面 的 代码 中 ， 我 们 只 通过 一 个 循环 向 it 中 填 入 了 前 32 项 内 容 ， 这 是 因为 在 整个 初期 设 
置 阶段 ， 中 断 是 禁用 的 。 early_idt_handler_array 数组 中 的 每 一 项 指向 的 都 是 同一 个 通用 中 
断 处 理 程序 ， 定 义 在 arch/x86/kernel/head 64.S。 我 们 先 暂 时 跳 过 这 个 数组 的 内 容 ， 看 一 下 


set_intr_gate 的 定义 。 


set_intr_gate 宏 定义 在 arch/x86/include/asm/desc.h : 


#define set_intr_gate(n, addr) N 


do { N 
BUG_ON((unsigned)n > OxFF); \ 
_set_gate(n, GATE_INTERRUPT, (void *)addr, 0, 0, N 

__KERNEL_CS); N 
_trace_set_gate(n, GATE_INTERRUPT, (void *)trace_##addr,\ 
0, ©, __KERNEL_CS); 
} while (0) 


HA BuG ON 宏 确 保 了 传 入 的 中 断 向 量 号 不 会 大 于 255， 因 为 我 们 最 多 只 有 256 个 中 断 。 然 
后 它 调 用 了 _set_gate 函数 ， 它 会 将 中 断 门 写 入 IDT 


static inline void _set_gate(int gate, unsigned type, void *addr, 
unsigned dpl, unsigned ist, unsigned seg) 


{ 
gate_desc s; 
pack_gate(&s, type, (unsigned long)addr, dpl, ist, seg); 
write_idt_entry(idt_table, gate, &s); 
write_trace_idt_entry(gate, &s); 

} 


在 _Set_gate 函数 的 开始 ， 它 调用 了 pack_gate 函数 。 这 个 函数 会 使 用 给 定 的 参数 十 充 


gate_desc 结构 : 


static inline void pack_gate(gate_desc *gate, unsigned type, unsigned long func, 
unsigned dpl, unsigned ist, unsigned seg) 


{ 
gate->offset_low = PTR_LOW(func); 
gate->segment = __KERNEL_CS; 
gate->ist = ist; 
gate->p = i 
gate->dpl = dpl; 
gate->zero0 = 0; 
gate->zero1 = (ly 
gate->type = type; 
gate->offset_middle = PTR_MIDDLE( func); 
gate->offset_high = PTR_HIGH(func); 
} 


在 这 个 函数 里 ， 我 们 把 从 主 循环 中 得 到 的 中 断 处 理 程序 入 口 点 地 址 拆 成 三 个 部 分 ， 填 入 门 描 
述 符 中 。 下 面 的 三 个 宏 就 用 来 做 这 个 拆 分 工作 : 


#define PTR_LOW(x) ((unsigned long long)(x) & OxFFFF) 
#define PTR_MIDDLE(x) (((unsigned long long)(x) >> 16) & OxFFFF) 
#define PTR_HIGH(x) ((unsigned long long)(x) >> 32) 


调用 pTR_LOW 可 以 得 到 X 的 低 2 个 字 节 | PTR_MIDDLE 可 以 得 到 X 的 中 间 2 AF 
节 ， 调 用 PTR_HIGH 则 能 够 得 到 X 的 高 4 个 字 节 。 接 下 来 我 们 来 位 中 断 处 理 程序 设置 段 选 
择 子 ， 即 内 核 代 码 段 ”KERNEL CS 。 然 后 将 Interrupt Stack Table 和 ”描述 符 特权 等 级 (最 高 
特权 等 级 ) 设置 为 0， 以 及 在 最 后 设置 GAT_INTERRUPT 类 型 。 


现在 我 们 已 经 设置 好 了 IDT 中 的 一 项 ， 那 么 通过 调用 native_write_idt_entry 函数 来 把 复制 
到 IDT 


static inline void native_write_idt_entry(gate_desc *idt, int entry, const gate_desc * 
gate) 


{ 
memcpy(&idt[entry], gate, sizeof(*gate)); 


} 


主 循环 结束 后 ， idt_table 就 已 经 设置 完毕 了 ， 其 为 一 个 gatedesc 数组 。 然 后 我 们 就 可 以 
通过 下 面 的 代码 加 载 中 断 描述 符 表 


load_idt((const struct desc ptr *)&idt_descr); 
其 中 ，idt descr 为 : 

struct desc_ptr idt_descr = { NR_VECTORS * 16 - 1, (unsigned long) idt_table }; 
load_idt 函数 只 是 执行 了 一 下 lidt 指令 


asm volatile("lidt %0"::"m" (*dtr)); 


你 可 能 已 经 注意 到 了 ， 在 代码 中 还 有 对 _trace * HAAA o AERAR _set_gate 
同样 的 方法 对 IDT 门 进行 设置 ， 但 仅 有 一 处 不 同 : | idt_table ， 而 是 
trace_idt_table ， 用 于 设置 追踪 点 (tracepoint， 我 们 将 会 在 其 他 章节 介绍 这 一 部 分 ) 。 


好 了 ， 至 此 我 们 已 经 了 解 到 ， 通 过 设置 并 加 载 中 断 描述 符 表 ， 能 够 让 CPU 在 发 生 中 断 时 做 出 
相应 的 动作 。 下 面 让 我 们 来 看 一 下 如 何 编 写 中 断 处 理 程序 。 


初期 中 断 处 理 程 原 


在 上 面 的 代码 中 ， 我 们 用 early_idt_handler_array 的 地 址 来 填充 了 IDT ， 这 个 
early_idt_handler_array 定义 在 arch/x86/kernel/head_64.S : 


.globl early_idt_handler_array 
early_idt_handlers: 

i=0 

.rept NUM_EXCEPTION_VECTORS 

.if (EXCEPTION_ERRCODE_MASK >> i) & 1 

pushq $0 

.endif 

pushq $i 

jmp early_idt_handler_common 

i=i+1 

.fill early_idt_handler_array + i*EARLY_IDT_HANDLER_SIZE - ., 1, Oxcc 

„endr 


这 段 代码 自动 生成 为 前 32 个 异常 生成 了 中 断 处 理 程序 。 首 先 ， 为 了 统一 栈 的 布局 ， 如 果 一 
个 异常 没有 返回 错误 码 ， 那 么 我 们 就 手动 在 栈 中 压 入 一 个 o 。 然 后 再 在 栈 中 压 入 中 断 向 量 
号 ， 最 后 跳 转 至 通用 的 中 断 处 理 程 序 early_idt_handler_common 。 我 们 可 以 通过 objdump 命 
令 的 输出 一 探究 竟 : 


$ objdump -D vmlinux 


ffffffff81fe5000 <early_idt_handler_array>: 


ffffffff81fe5000: 6a 00 pushq $0x0 

ffffffff81fe5002 : 6a 00 pushq $0x0 

ffffffff81fe5004 : e9 17 01 00 00 jmpq ffffffff81fe5120 <early_idt_han 
dler_common> 

ffffffff81fe5009: 6a 00 pushq $0x0 

ffffffff81fe500b: 6a 01 pushq $0x1 

ffffffff81fe500d : e9 Oe 01 00 00 jmpq ffffffff81fe5120 <early_idt_han 
dler_common> 

ffffffff81fe5012 : 6a 00 pushq $0x0 

ffffffff81fe5014: 6a 02 pushq $0x2 


由 于 在 中 断 发 生 时 ，CPU 会 在 栈 上 压 入 标志 寄存 器 、 cs 
因此 在 early_idt_handler 执行 前 ， 栈 的 布局 如 下 : 


75 840 RIP 寄存 器 的 内 容 。 


水 
ty 


| %rflags | 
| %cs | 
| %rip | 
| 


| rsp --> error code 


下 面 我 们 来 看 一 下 early_idt_handler_common 的 实现 。 它 也 定义 在 
arch/x86/kernel/head_64.S 文件 中 。 首 先 它 会 检查 当前 中 断 是 否 为 不 可 屏蔽 中 断 (NMN) ， 如 
果 是 则 简单 地 忽略 它们 : 


cmpl $2, (%rsp) 
je .Lis_nmi 


其 中 is_nmi A: 


is_nmi: 
addq $16,%rsp 
INTERRUPT_RETURN 


这 段 程序 首先 从 栈 顶 弹出 错误 码 和 中 断 向 量 号 ， 然 后 通过 调用 INTERRUPT_RETURN ， 即 
iretq 指令 直接 返回 。 


如 果 当 前 中 断 不 是 NMI ， 则 首先 检查 early_recursion flag 以 避免 在 
early_idt_handler_common 程序 中 递归 地 产生 中 断 。 如 果 一 切 都 没 问 题 ， 就 先 在 栈 上 保存 通 
用 寄存 器 ， 为 了 防止 中 断 返回 时 寄存 器 的 内 容错 乱 : 


pushq %rax 
pushq %rcx 
pushq %rdx 
pushq %rsi 
pushq %rdi 
pushq %r8 

pushq %r9 

pushq %r10 
pushq %r11 


然后 我 们 检查 栈 上 的 段 选择 子 : 


cmpl $__KERNEL_CS, 96(%rsp) 
jne 11f 


段 选择 子 必 须 为 内 核 代 码 段 ， 如 果 不 是 则 跳 转 到 标签 11 ， 输 出 pance 信息 并 打印 栈 的 内 
容 。 然 后 我 们 来 检查 向 量 号 ， 如 果 是 #pPF 即 缺 页 中 断 (Page Fault) ， 那 么 就 把 cr2 寄存 


ES 中 的 值 赋值 给 rdi ， 然 后 调用 early_make_pgtable (4# 见 后 文 ) 


cmpl $14,72(%rsp) 

jnz 10f 
GET_CR2_INTO(%rdi) 

call early_make_pgtable 
andl %eax, %eax 

jz 20f 


如 果 向 量 号 不 是 #pF ， 那 么 就 恢复 通用 寄存 器 : 


popq %r11 
popq %r10 
popq %r9 

popq %r8 

popq %rdi 
popq %rsi 
popq %rdx 
popq %rcx 
popq %rax 


并 调用 iret 从 中 断 处 理 程序 返回 。 


第 一 个 中 断 处 理 程序 到 这 里 就 结束 了 。 由 于 它 只 是 一 个 初期 中 段 处 理 程序 ， 因 此 只 处 理 缺 页 
中 断 。 下 面 让 我 们 首先 来 看 一 下 缺 页 中 断 处 理 程序 ， 其 他 中 断 的 处 理 程序 我 们 之 后 再 进行 分 
析 。 


缺 页 中 断 处 理 程序 


在 上 一 节 中 我 们 第 一 次 见 到 了 初期 中 断 处 理 程序 ， 它 检查 了 缺 页 中 断 的 中 断 号 ， 并 调用 了 
early_make_pgtable 来 建立 新 的 页 表 。 在 这 里 我 们 需要 提供 #pF 中 断 处 理 程序 ， 以 便 为 之 
后 将 内 核 加 载 至 46 地 址 以 上 ， 并 且 能 访问 位 于 4G 以 上 的 boot_params 结构 体 。 
early_make_pgtable 的 实现 在 arch/x86/kernel/head64.c， 它 接受 一 个 参数 : 从 cr2 寄存 器 
得 到 的 地 址 ， 这 个 地 址 引发 了 内 存 中 断 。 下 面 让 我 们 来 看 一 下 : 


int __init early_make_pgtable(unsigned long address) 
{ 
unsigned long physaddr = address - __PAGE_OFFSET; 
unsigned long i; 
pgdval_t pgd, *pgd_p; 
pudval_t pud, *pud_p; 
pmdval_t pmd, *pmd_p; 


首先 它 定义 了 一 些 *val t 类 型 的 变量 。 这 些 类 型 均 为 : 


typedef unsigned long pgdval_t; 


此 外 ， 我 们 还 会 遇见 *_t (不 带 val) 的 类 型 ， 比 如 pgat ...... 这 些 类 型 都 定义 在 
arch/x86/include/asm/pgtable_types.h， 形 式 如 下 : 


typedef struct { pgdval_t pgd; } pgd t; 


例如 ， 
extern pgd_t early_level4_pgt[PTRS_PER_PGD]; 
在 这 里 early_level4_pgt 代表 了 初期 顶层 页 表 目 录 ， 它 是 一 个 pdg_t 类 型 的 数组 ， 其 中 的 


pgd 指向 了 下 一 级 页 表 。 


在 确认 不 是 非法 地 址 后 ， 我 们 取得 页 表 中 包含 引起 gpr 中 断 的 地 址 的 那 一 项 ， 将 其 赋值 给 


pgd 变量 : 


pgd_p = &early_level4_pgt[pgd_index(address)].pgd; 
pgd = *pgd_p; 


接 下 来 我 们 检查 一 下 pgd ， 如 果 它 包含 了 正确 的 全 局 页 表 项 的 话 ， 我 们 就 把 这 一 项 的 物理 地 
址 处 理 后 赋值 给 pud_p 


pud_p = (pudval_t *)((pgd & PTE_PFN_MASK) + __START_KERNEL_map - phys_base); 





其 中 PTE_PFN_MASK 是 一 个 宏 : 


#define PTE_PFN_MASK ((pteval_t ) PHYSICAL_PAGE_MASK) 


展开 后 将 为 : 


(~(PAGE_SIZE-1)) & ((1 << 46) - 1) 


或 者 写 为 : 


0b1111111111111111111111111111111111111111111111 


它 是 一 个 46bit 大 小 的 页 帧 屏蔽 值 。 


如 果 pgd 没有 包含 有 效 的 地 址 ， 我 们 就 检查 next_early_pgt 与 

EARLY_DYNAMIC_PAGE_TABLES (PP 64 ) 的 大 小 。 EARLY_DYNAMIC_PAGE_TABLES 它 是 一 个 固定 大 
小 的 缕 冲 区 ， 用 来 在 需要 的 时 候 建 立新 的 页 表 。 如 果 next_early pgt 比 
EARLY_DYNAMIC_PAGE_TABLES 大 ， 我 们 就 用 一 个 上 层 页 目录 指针 指向 当前 的 动态 页 表 ， 并 将 它 
的 物理 地 址 与 _kERPG_TABLE 访问 权限 一 起 写 入 全 局 页 目录 表 : 


if (next_early_pgt >= EARLY_DYNAMIC_PAGE_TABLES) { 
reset_early_page_tables(); 
goto again; 


} 


pud_p = (pudval_t *)early_dynamic_pgts[next_early_pgt++]; 
for (i = 0; i < PTRS_PER_PUD; i++) 
pud_p[i] = 0; 
*pgd_p = (pgdval_t)pud_p - START_KERNEL_map + phys_base + _KERNPG_TABLE; 





然后 我 们 来 修正 上 层 页 目录 的 地 址 : 


pud_p += pud_index(address); 
pud = *pud_p; 


下 面 我 们 对 中 层 页 目录 重复 上 面 同样 的 操作 。 最 后 我 们 利用 In the end we fix address of the 
page middle directory which contains maps kernel text+data virtual addresses: 


pmd = (physaddr & PMD_MASK) + early_pmd_flags; 
pmd_p[pmd_index(address)] = pmd; 


到 此 缺 页 中 断 处 理 程序 就 完成 了 它 所 有 的 工作 ， 此 时 early_level4 ppt 就 包含 了 指向 合法 地 
址 的 项 。 


本 书 的 第 二 部 分 到 此 结束 了 。 


如 果 你 有 任何 问题 或 建议 ， 请 在 twitter 上 联系 我 0XKXAX， 或 者 通过 邮件 与 我 沟通 ， 还 可 以 新 
开 issue。 


接 下 来 我 们 将 会 看 到 进入 内 核 入 口 点 start_kernel 函数 之 前 剩 下 所 有 的 准备 工作 。 


相关 链接 


e GNU assembly .rept 


早期 的 中 断 和 异常 控制 


e APIC 

e NMI 

e Page table 

e Interrupt handler 
e Page Fault, 

e Previous part 
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进入 内 核 入 口 点 之 前 最 后 的 准备 工作 


这 是 Linux Paaa CaL DH 第 三 部 分 。 在 上 一 个 部 分 中 我 们 接触 到 了 初期 中 断 和 异常 处 

理 ， 而 在 这 个 部 分 中 我 们 要 继 给 Lk 看 Linux 内 核 的 初始 化 过 程 。 在 之 后 的 章节 我 们 将 会 

注 “ 内 核 入 口 点 ”一 一 init/main.c 文件 中 的 start_kernel 函数 。 没 错 ， 从 技术 上 说 这 ney 
核 的 入 口 点 ， 只 是 不 依赖 于 特定 架构 的 通用 内 核 代 码 的 开始 。 不 过 ， 在 我 们 调用 
start_kernel 之 前 ， 有 些 准 备 必 须要 做 。 下 面 我 们 就 来 看 一 看 。 


boot_params again 


在 上 一 个 部 分 中 我 们 讲 到 了 设置 中 断 描述 符 表 ， 并 将 其 加 载 进 IDTR 寄存 器 。 下 一 步 是 调用 


copy_bootdata 函数 : 


copy_bootdata(__va(real_mode_data) ); 





这 个 函数 接受 一 个 参数 read_mode_data 的 虚拟 地 址 。 boot _params 结构 体 是 在 
arch/x86/include/uapi/asm/bootparam.h 作为 第 一 个 参数 传递 到 arch/x86/kernel/head_64.S 
中 的 x86_64_start_kernel AHY : 


/* rsi is pointer to real mode structure with interesting info. 
pass it to C */ 
movq %rsi, %rdi 


下 面 我 们 来 看 一 看 _va 宏 。 这 个 宏 定 义 在 init/main.c: 


#define _ va(x) ((void *)((unsigned long)(x)+PAGE_OFFSET)) 


其 中 PAGE_ OFFSET 就 是 ”PAGE OFFSET (FP oxffffssoooooooo00 ) ， 也 是 所 有 对 物理 地 址 进 

行 直接 映射 后 的 虚拟 基地 址 。 因 此 我 们 就 得 到 了 boot _params 结构 体 的 虚拟 地 址 ， 并 把 他 传 
入 copy_bootdata 函数 中 。 在 这 个 函数 里 我 们 把 real mod data (定义 在 
arch/x86/kernel/setup.h) 拷贝 进 boot_params 


extern struct boot_params boot_params; 


copy_boot_data 的 实现 如 下 : 


static void _ init copy_bootdata(char *real_mode_data) 
{ 

char * command_line; 

unsigned long cmd_line_ptr; 


memcpy(&boot_params, real_mode_data, sizeof boot_params); 
sanitize_boot_params(&boot_params) ; 
cmd_line_ptr = get_cmd_line_ptr(); 
if (cmd_line_ptr) { 
command_line = __va(cmd_line_ptr); 
memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE); 





首先 ， 这 个 函数 的 声明 中 有 一 个 init 前 缓 ， 这 表示 这 个 函数 只 在 初始 化 阶段 使 用 ， 并 且 
它 所 使 用 的 内 存 将 会 被 释放 。 


在 这 个 函数 中 首先 声明 了 两 个 用 于 解析 内 核 命 令 行 的 变量 ， 然 后 使 用 memcpy 函数 将 
real_mode_data 拷贝 进 poot_params 。 如 果 系 统 引 导 工 具 (bootloader) 没 能 正确 初始 化 
boot_params PAV sk RR ATE > AA HFEF RAIA AY sanitize_boot_params 函数 中 将 会 对 
这 些 成 员 进 行 清 零 ， 比 如 ext_ramdisk_image 等 。 此 后 我 们 通过 调用 get_cmd_line_ptr 函数 
来 得 到 命令 行 的 地 址 : 


unsigned long cmd_line_ptr = boot_params.hdr.cmd_line_ptr; 
cmd_line_ptr |= (u64)boot_params.ext_cmd_line_ptr << 32; 
return cmd_line_ptr; 


get_cmd_line_ptr 函数 将 会 从 boot_params 中 获得 命令 行 的 64 位 地 址 并 返回 。 最 后 ， 我 们 检 
查 一 下 是 否 正 确 获得 了 cmd_line_ptr ， 并 把 它 的 虚拟 地 址 拷贝 到 一 个 字 节 数组 


boot_command_line 中 : 


extern char __initdata boot_command_line[]; 


这 一 步 完 成 之 后 ， 我 们 就 得 到 了 内 核 命令 行 和 boot_params nce 之 后 ， 内 核 通 过 调用 
load_ucode_bsp 哆 数 来 加 载 处 理 器 微 代码 (microcode) ， 不 过 我 们 目前 先 暂时 忽略 这 


步 。 
微 代码 加 载 之 后 ， 内 核 会 对 console loglevel 进行 检查 ， 同 时 通过 early_printk 函数 来 打 
印 出 字符 串 Kernel Alive 。 不 过 这 个 输出 不 会 虽 的 被 显示 出 来 ， 因 为 这 个 时 候 

early_printk 还 没有 被 初始 化 。 这 是 目前 ee bug， 作 者 已 经 提交 了 补丁 
commit， 补 丁 很 快 就 能 应 用 在 主 分 支 中 了 。 所 以 你 可 以 先 跳 过 这 段 代码 。 


初始 化 内 存 页 


至 此 ， 我 们 已 经 拷贝 了 boot_params 结构 体 ， 接 下 来 将 对 初期 页 表 进 行 一 些 设置 以 便 在 初始 

化 内 核 的 过 程 中 使 用 。 我 们 之 前 已 经 对 初始 化 了 初期 页 表 ， 以 便 支 持 换 页 ， 这 在 之 前 的 部 分 
中 已 经 讨论 过 。 现 在 则 通过 调用 reset_early_page_tables 函数 将 初期 RAP 大 部 分 项 清 零 
(在 之 前 的 部 分 也 有 介绍 ) ， 只 保留 内 核 高 地 址 的 映射 。 然 后 我 们 调用 : 


clear_page(init_level4 pgt); 


init_level4_pgt 同样 定义 在 arch/x86/kernel/head_64.S: 


NEXT_PAGE(init_level4_ pgt) 








. quad level3_ident_pgt - START_KERNEL_map + _KERNPG_TABLE 
.Org init_level4_pgt + L4 PAGE_ OFFSET*8, 0 

.quad level3_ident_pgt - START_KERNEL_map + _KERNPG_TABLE 
.Org init_level4_pgt + L4_ START_KERNEL*8, 0 

. quad level3_kernel_pgt - START_KERNEL_map + _PAGE_TABLE 





这 段 代码 为 内 核 的 代码 段 、 数 据 段 和 bss 段 映射 了 前 2.56 个 字 节 。 clear_page WAC LE 
arch/x86/lib/clear_page 64.S : 


ENTRY(clear_page) 
CFI_STARTPROC 
xorl %eax, %eax 
movl $4096/64, %ecx 


.p2align 4 
.Lloop: 
decl %ECX 


#define PUT(X) movq %rax, x*8(%rdi) 
movq %rax, (%rdi) 
PUT(1) 

PUT(2) 

PUT(3) 

PUT(4) 

PUT(5) 

PUT(6) 

PUT(7) 

leaq 64(%rdi),%rdi 
jnz . Lloop 

nop 

ret 

CFI_ENDPROC 
.Lclear_page_end: 
ENDPROC(clear_page) 


顾名思义 ， 这 个 函数 会 将 页 表 清 零 。 这 个 函数 的 开始 和 结束 部 分 有 两 个 宏 CcFI_STARTPROC 和 
CFI_ENDPROC ， 他 们 会 展开 成 GNU 汇编 指令 ， 用 于 调试 : 


#define CFI_STARTPROC .cfi_startproc 
#define CFI_ENDPROC .cfi_endproc 


在 CFI_STARTPROC 之 后 我 们 将 eax 寄存 器 清 零 ， 并 将 ecx 赋值 为 64 (用 作 计 数 器 ) 。 接 
下 来 从 .Lloop 标签 开始 循环 ， 首 先 就 是 将 ecx 减 一 。 然 后 将 rax 中 的 值 (目前 为 0) 写 
A rdi 指向 的 地 址 ，rdi 中 保存 的 是 init_level4_pgt 的 基地 址 。 接 下 来 重复 7 次 这 个 步 
骤 ， 但 是 每 次 都 相对 rdi 多 偏 移 8 个 字 节 。 之 后 init_level4_pgt 的 前 64 个 字 节 就 都 被 填充 
为 0 了 。 接 下 来 我 们 将 rai 中 的 值 加 上 64， 重 复 这 个 步骤 ， 直 到 ecx REO. 最 后 就 完成 了 


将 init_level4_pgt X o 


在 将 init_level4_pgt 卉 0 之 后 ， 再 把 它 的 最 后 一 项 设置 为 内 核 高 地 址 的 映射 : 
init_level4 pgt[511] = early_level4 pgt[511]; 

在 前 面 我 们 已 经 使 用 reset_early page_table 函数 清除 early level4 pgt 中 的 大 部 分 项 ， 

而 只 保留 内 核 高 地 址 的 映射 。 


x86_64_start_kernel 函数 的 最 后 一 步 是 调用 : 


x86_64_start_reservations(real_mode_data); 


并 传 入 real_mode_data 参数 。 x86_64_start_reservations LEES] x86_64_start_kernel | 


数 定义 在 同一 个 文件 中 : 


void _ init x86° 64 start reservations(char “real mode data) 
{ 
if (!boot_params.hdr.version) 
copy_bootdata(_ va(real_mode_data)); 


reserve_ebda_region(); 


start_kernel(); 


这 就 是 进入 内 核 入 口 点 之 前 的 最 后 一 个 函数 了 。 下 面 我 们 就 来 介绍 一 下 这 个 函数 。 


Ma 


内 核 入 口 点 前 的 最 后 一 步 


在 x86_64_start_reservations 函数 中 首先 检查 了 boot_params.hdr.version 


if (!boot_params.hdr.version) 
copy_bootdata(__va(real_mode_data) ); 


如 果 它 为 0， 则 再 次 调用 copy_bootdata ， 并 传 入 real mode data 的 虚拟 地 址 。 


接 下 来 则 调用 了 reserve_ebda_region 函数 ， 它 定义 在 arch/x86/kernel/head.c。 这 个 函数 为 
EBDA ( 即 Extended BIOS Data Area， 扩 展 BIOS 数 据 区 域 ) 预 留 空间 。 扩 展 BIOS 预 留 区域 
位 于 常规 内 存 顶 部 (译注 : 常规 内 存 (Conventiional Memory) 是 指 前 640K 字 节 内 存 ) ， 包 
含 了 端口 、 磁 盘 参 数 等 数据 。 


接 下 来 我 们 来 看 一 下 reserve_ebda_region 部 数 。 它 首先 会 检查 是 否 启 用 了 半 虚 拟 化 : 


if (paravirt_enabled() ) 
return; 


如 果 开 司 了 半 虚 拟 化 ， 那 么 就 退出 reserve_ebda_region 函数 ， 因 为 此 时 没有 扩展 BIOS 数 据 
区 域 。 下 面 我 们 首先 得 到 低地 址 内 存 的 末尾 地 址 : 


lowmem = *(unsigned short *)__va(BIOS_LOWMEM_KILOBYTES) ; 
lowmem <<= 10; 


首先 我 们 得 到 了 BIOS 地 地 址 内 存 的 虚拟 地 址 ， 以 KB 为 单位 ， 然 后 将 其 左 移 10 位 ( 即 乘 以 
1024) 转换 为 以 字 节 为 单位 。 然 后 我 们 需要 获得 扩展 BIOS 数 据 区 域 的 地 址 : 


ebda_addr = get_bios_ebda(); 


其 中 ， get_bios_ebda HA XL arch/x86/include/asm/bios_ebda.h : 


static inline unsigned int get_bios_ebda(void) 


{ 
unsigned int address = *(unsigned short *)phys_to_virt(0x40E); 
address <<= 4; 
return address; 

} 


下 面 我 们 来 尝试 理解 一 下 这 段 代 码 。 这 段 代 码 中 ， 首 先 我 们 将 物理 地 址 gx46E 转换 为 虚拟 地 
dE > 9x0040:0x000e 就 是 包含 有 扩展 BIOS 数 据 区 域 基地 址 的 代码 段 。 这 里 我 们 使 用 了 
phys_to_virt 函数 进行 地 址 转换 ， 而 不 是 之 前 使 用 的 va 宏 。 不 过 ， 事 实 上 他 们 两 个 基本 
上 是 一 样 的 : 


static inline void *phys_to_virt(phys_addr_t address) 
{ 


return __va(address); 


而 不 同 之 处 在 于 ， phys_tovirt 函数 的 参数 类 型 phys addr_t 的 定义 依赖 于 


CONFIG_PHYS_ADDR_T_64BIT 


#ifdef CONFIG_PHYS_ADDR_T_64BIT 
typedef u64 phys_addr_t; 
#else 
typedef u32 phys_addr_t; 
#endif 


具体 的 类 型 是 由 CONFIG_PHYS_ADDR_T_64BIT 设置 选项 控制 的 。 此 后 我 们 得 到 了 包含 扩展 BIOS 
数据 区 域 庶 拟 基地 址 的 自 ? 把 它 左 移 4 位 后 返回 和 这 样 ” ebda_addr 变量 就 包含 了 扩展 BIOS 
数据 区 域 的 基地 址 。 


下 一 步 我 们 来 检查 扩展 BIOS 数 据 区 域 与 低地 址 内 存 的 地 址 ， 看 一 看 它们 是 否 小 于 


INSANE_CUTOFF Æ : 


if (ebda_addr < INSANE_CUTOFF) 
ebda_addr = LOWMEM_CAP; 


if (lowmem < INSANE_CUTOFF) 


lowmem = LOWMEM_CAP; 


INSANE_CUTOFF 为 : 


#define INSANE_CUTOFF 0x20000U 


BP 128 KB. 上 一 步 我 们 得 到 了 低地 址 内 存 中 的 低地 址 部 分 以 及 扩展 BIOS 数 据 区 域 ， 然 后 调用 
memblock_reserve 函数 来 在 低 内 存 地 址 与 1MB 之 间 为 扩展 BIOS 数 据 预 留 内 存 区 域 。 


lowmem = min(lowmem, ebda_addr); 
lowmem = min(lowmem, LOWMEM_CAP); 
memblock_reserve(lowmem, 0x100000 - lowmem); 


memblock_reserve Wake LE mm/block.c， 它 接受 两 个 参数 : 


e 基 物 理 地 址 
。 区 域 大 小 


然后 在 给 定 的 基地 址 处 预 留 指 ZAT 的 内 存 ° memblock_reserve 是 在 这 本 书 中 我 们 接触 到 的 
第 一 个 Linux 内 核 内 存 管 理 框 架 中 的 隐 数 。 我 们 很 快 会 详细 地 介绍 内 存 管理 ， 不 过 现在 还 是 先 
来 看 一 看 这 个 函数 的 实现 。 


Linux 内 核 管 理 框 架 初 探 


在 上 一 段 中 我 们 遇 到 了 对 memblock_reserve 函数 的 调用 。 现 在 我 们 来 党 试 理解 一 下 这 个 函数 
是 如 何 工 作 的 。 memblock_reserve 函数 只 是 调用 了 : 


memblock_reserve_region(base, size, MAX_NUMNODES, 0); 


memblock_reserve_region 接受 四 个 参数 : 


© 内 存 区 域 的 物理 基地 址 
© 内 存 区 域 的 大 小 

。 最 大 NUMA 节点 数 

。 标志 参数 flags 


在 memblock_reserve_region 函数 一 开始 ， 就 是 一 个 memblock_type 结构 体 类 型 的 变量 : 


struct memblock_type *_rgn = &memblock.reserved; 


memblock_type 类 型 代表 了 一 块 内 存 ， 定 义 如 下 : 


struct memblock_type { 
unsigned long cnt; 
unsigned long max; 
phys_addr_t total_size; 
struct memblock_region *regions; 


}; 


因为 我 们 要 为 扩展 BIOS 数 据 区 域 预 留 内 存 块 ， 所 以 当前 内 存 区 域 的 类 型 就 是 预 留 。 memblock 
结构 体 的 定义 为 : 


struct memblock { 
bool bottom_up; 
phys_addr_t current_limit; 
struct memblock_type memory; 
struct memblock_type reserved; 
#ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP 
struct memblock_type physmem; 
#endif 


i 


它 描述 了 一 块 通用 的 数据 块 。 我 们 用 memblock.reserved 的 值 来 初始 化 _rgn ° memblock 


H> 


struct memblock memblock __initdata_memblock = { 


.memory.regions = memblock_memory_init_regions, 
.memory.cnt = i, 

. memor y . max = INIT_MEMBLOCK_REGIONS, 
.reserved.regions = memblock_reserved_init_regions, 
.reserved.cnt = 1, 


. reserved .max INIT_MEMBLOCK_REGIONS, 
#ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP 


.physmem. regions = memblock_physmem_init_regions, 
. physmem. cnt = 1, 
. physmem.max = INIT_PHYSMEM_REGIONS, 
#endif 
.bottom_up = false, 
.current_limit = MEMBLOCK_ALLOC_ANYWHERE, 
J; 


我 们 现在 不 会 继续 深究 这 个 变量 ， 但 在 内 存 管理 部 分 的 中 我 们 会 详细 地 对 它 进 行 介绍 。 需 要 
注意 的 是 ， 这 个 变量 的 声明 中 使 用 了 _ initdata_memblock 


#define _ initdata memblock __meminitdata 


而 ”meminit data A: 


#define _ meminitdata __section(.meminit.data) 


自 此 我 们 得 出 这 样 的 结论 : 所 有 的 内 存 块 都 将 定义 在 .meminit.data 区 段 中 。 在 我 们 定义 了 
_rgn 之 后 ， 使 用 了 memblock_dbg 宏 来 输出 相关 的 信息 。 你 可 以 在 从 内 核 命令 行 传 入 参数 
memblock=debug 来 开启 这 些 输 出 。 


在 输出 了 这 些 调试 信息 后 ， 是 对 下 面 这 个 函数 的 调用 : 


memblock_add_range(_rgn, base, size, nid, flags); 


Ee) .meminit.data 区 段 添 加 了 一 个 新 的 内 存 块 区 域 。 由 于 _rgn 的 值 是 
&memblock.reserved ， 下 面 的 代码 就 直接 将 扩展 BIOS 数 据 区 域 的 基地 址 、 大 小 和 标志 填 入 
_rgn 中 : 


if (type->regions[0].size == 0) { 
WARN_ON(type->cnt != 1 || type->total_size); 
type->regions[0].base = base; 
type->regions[0].size = size; 
type->regions[0].flags = flags; 
memblock_set_region_node(&type->regions[0], nid); 
type->total_size = size; 
return 0; 


在 填充 好 了 区 域 后 ， 接着 是 对 memblock_set_region_node 函数 的 调用 。 它 接受 两 个 参数 : 


。 填充 好 的 内 存 区 域 的 地 址 
e NUMA 节 点 ID 


其 中 我 们 的 区 域 由 memblock_region 结构 体 来 表示 : 


struct memblock_region { 
phys_addr_t base; 
phys_addr_t size; 
unsigned long flags; 
#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP 
int nid; 
#endif 
}; 


NUMA 节 点 ID 依赖 于 MAx_NuUMNODES 宏 ， 定 义 在 include/linux/numa.h 


#define MAX_NUMNODES (1 << NODES_SHIFT) 


其 中 NoDES_SHIFT 依赖 于 CONFIG_NODES SHIFT 配置 参数 ， 定 义 如 下 : 


#ifdef CONFIG_NODES_SHIFT 


#define NODES SHIFT CONFIG_NODES_SHIFT 
#else 

#define NODES SHIFT 0 
#endif 


memblick_set_region_node 函数 只 是 填充 了 memblock_region 中 的 nid 成 员 : 


static inline void memblock_set_region_node(struct memblock_region *r, int nid) 


{ 


r->nid = nid; 


在 这 之 后 我 们 就 在 .meminit.data 区 段 拥有 了 为 扩展 BIOS 数 据 区 域 预 留 的 第 一 个 
memblock ° reserve_ebda_region 已 经 完成 了 它 该 做 的 任务 ， 我 们 回 到 
arch/x86/kernel/head64.c 继续 。 


至 此 我 们 已 经 结束 了 进入 内 核 之 前 所 有 的 准备 工作 ° x86_64_start_reservations 的 最 后 一 步 
是 调用 init/main.c 中 的 : 


start_kernel() 
这 一 部 分 到 此 结 


小 结 
到 内 核 入 口 点 处 的 初始 化 工作 


本 书 的 第 三 部 分 到 这 里 就 结束 了 。 在 下 一 部 分 中 ， 我 们 将 会 见 
个 进程 init 之 前 首先 要 完成 的 工 


一 一 位 于 start_kernel 哆 数 中 。 这 些 工作 是 在 启动 第 一 人 
作 。 
如 果 你 有 任何 问题 或 建议 ， 请 在 twitter 上 联系 我 0XAX， 或 者 通过 邮件 与 我 沟通 ， 还 可 以 新 


J issue ° 


相关 链接 


e BIOS data area 
e What is in the extended BIOS data area on a PC? 
e Previous part 


内 核 初始 化 , Part 4. 


Kernel entry point 


还 记得 上 一 章 的 内 容 吗 - 跳 转 到 内 核 入 口 之 前 的 最 后 准备 ? 你 应 该 还 记得 我 们 已 经 完成 一 系列 
初始 化 操作 ， 并 停 在 了 调用 位 于 init/main.c 中 的 start_kernel 函数 之 前 . start_kernel 函数 
是 与 体系 架构 无 关 的 通用 处 理 入 口 函 数 ， 尽 管 我 们 在 此 初始 化 过 程 中 要 无 数 次 的 返回 arch/ X 
件 夹 。 如 果 你 仔细 看 看 start_kernel WAH) AS >? 你 将 发 现 此 函数 涉及 内 容 非常 广 泛 。 在 此 
过 程 中 约 包含 了 86 个 调用 函数 ， 是 的 ， 你 发 现 它 卜 的 是 非常 庞大 但 是 此 部 分 并 不 是 全 部 的 初 
始 化 过 程 ， 在 当前 阶段 我 们 只 看 这 些 就 可 以 了 。 此 章节 以 及 后 续 所 有 在 内 核 初始 化 过 程 章节 
的 内 容 将 涉及 并 详 述 它 。 


start_kernel 远 数 的 主要 目的 是 完成 内 核 初始 化 并 启动 祖先 进程 (1 号 进程 )。 在 祖先 进程 启动 
之 前 start_kernel 函数 做 了 很 多 事情 ， 如 锁 验 证 器 ,根据 处 理 器 标识 ID 初始 化 处 理 器 ， 开 局 
cgroups 子 系统 ， 设 置 每 CPU 区 域 环境 ， 初 始 化 VFS Cache 机 制 ， 初 始 化 内 存 管理 ， 
rcu,vmalloc,scheduler( 调 度 器 ),IRQs( 中 断 向 量 表 ),ACPI( 中 断 可 编程 控制 器 ) 以 及 其 它 很 多 子 系 
统 。 只 有 经 过 这 些 步骤 我 们 才 看 到 本 章 最 后 一 部 分 祖先 进程 启动 的 过 程 ; 同志 们 ， 如 此 复杂 
的 内 核子 系统 ， 有 没有 义 起 你 的 学 习 和 欲望 ， 有 这 么 多 的 内 核 代 码 等 着 我 们 去 征服 ， 让 我 们 开 
始 吧 “。 


注意 :在 此 大 章节 的 所 有 内 容 Linux Kernel initialization process ， 并 不 涉及 内 核 调试 相 
关 ， 关 于 内 核 调试 部 分 会 有 一 个 单独 的 章节 来 进行 描述 
关于 _ attribute _ 


正如 我 上 述 所 写 ， start_kernel WRX LE init/main.c. A GF RAY PKA AEA E] th BH BE 
用 了 _ init 特性 ? 你 也 许 从 其 它 地 方 了 解 过 关于 GCC _ attribute __ 78 关 的 内 全 2 在 内 核 初 
始 化 阶段 这 个 机 制 在 所 有 的 函数 中 都 是 有 必要 的 。 


#define _ init __section(.init.text) _ cold notrace 


在 初始 化 过 程 完成 后 ， 内 核 将 通过 调用 free_initmem 释放 这 些 sections( 段 )。 注意 _init 属 
性 是 通过 cold 和 notrace 两 个 属性 来 定义 的 。 第 一 个 属性 cold 的 目的 是 标记 此 函数 很 少 
使 用 所 以 编译 器 必须 优化 此 函数 的 大 小 ， 第 二 个 属性 notrace 定义 如 下 : 


#define notrace __attribute__((no_instrument_function) ) 


含有 no_instrument_function 意思 就 是 告诉 编译 器 函数 调用 不 产生 环境 变量 (堆栈 空间 ) 。 


在 start_kernel 函数 的 定义 中 ， 你 也 可 以 看 到 visible 属性 的 扩展 : 


#define _ visible __attribute__((externally_visible) ) 


含有 externally visible 意思 就 是 告诉 编译 器 有 一 些 过 程 在 使 用 该 函数 或 者 变量 ， 为 了 放 至 
标记 这 个 郊 数 /变量 是 unusable 。 你 可 以 在 此 includeWinuxinit.h 处 查 到 这 些 属 ， aren 式 的 含 
3 o 


start_kernel 初始 化 
在 start_kernel 的 初始 之 初 你 可 以 看 到 这 两 个 变量 : 


char *command_line; 
char *after_dashes; 


第 一 个 变量 表示 内 核 命令 行 的 全 局 指针 ? 第 二 个 变量 将 包含 parse_args 函数 通过 才 输 入 字符 串 
中 的 参数 name=value'， 寻 找 特 定 的 关键 字 和 调用 正确 的 处 理 程序 。 我 们 不 想 在 这 个 时 候 参 与 
这 两 个 变量 的 相关 细节 ， 但 是 会 在 接 下 来 的 章节 看 到 。 我 们 接着 往 下 走 ， 下 一 步 我 们 看 到 了 
此 函数 : 


lockdep_init(); 


lockdep_init 初始 化 lock validator. 其 实现 是 相当 简单 的 ， 它 只 是 初始 化 了 两 个 哈 希 表 
list_head 并 设置 lockdep_initialized 全 局 变量 为 1 。 关于 自 旋 锁 spinlock 以 及 互 不 
锁 mutex 如 何 获 取 请 参考 链接 . 


下 一 个 函数 是 set_task_stack_end_magic ， 参 数 为 init_task 和 设置 STACK_END_MAGIC 
( ex57AC6E9D )° init_task 代表 初始 化 进程 (任务 ) 数 据 结构 : 





struct task_struct init_task = INIT_TASK(init_task); 


task_struct 存储 了 进程 的 所 有 相关 信息 。 国 为 它 很 庞大 ， 我 在 这 本 书 并 不 会 去 介绍 ， 详 细 
信息 你 可 以 查看 调度 相关 数据 结构 定义 头 文件 include/linux/sched.h。 在 此 刻 task_sreuct 包 
含 了 超过 100 个 字段 ! 虽然 你 不 会 看 到 task_struct 是 在 这 本 书 中 的 解释 ， 但 是 我 们 会 经 常 
使 用 它 ， 因 为 它 是 介绍 在 Linux 内 核 进程 的 基本 知识 。 我 将 描述 这 个 结构 中 字段 的 一 些 含义 ， 
因为 我 们 在 后 面 的 实践 中 见 到 它们 。 


你 也 可 以 查看 init_task 的 相关 定义 以 及 宏 指 令 
include/linux/init_task.h 在 此 刻 只 是 设置 和 初始 化 了 第 


INIT_TASK 的 初始 化 流程 。 这 个 宏 指 令 来 自 于 


个 进程 来 (0 号 进程 ) 的 值 。 例 如 这 么 设 


a: 


© 初始 化 进程 状态 为 zero 或 者 runnable . 一 个 可 运 和 

e 初始 化 仅 存 的 标志 位 - PF_KTHREAD 意思 为 - oe 
© 一 个 可 运行 的 任务 列表 ; 

。 进程 地 址 空间 ; 


° 初始 化 进程 堆栈 &init_thread_info - init_thread_union.thread_info 和 


进程 即 为 等 待 CPU 去 运行 ; 


initthread_union 使 用 共用 体 - thread_union 包含 了 thread_info 辽 进程 信息 息 以 及 进程 
Bas 。 


union thread_union { 

struct thread_info thread_info; 

unsigned long stack[THREAD_SIZE/sizeof(long)]; 
J; 


每 个 进程 都 有 其 自己 的 堆栈 ， x86_64 架构 的 CPU 一 般 支 持 的 页 表 是 16KB or 4 个 页 框 大 小 。 
我 们 注意 stack 变 量 被 定义 为 数据 并 且 类 型 是 unsigned long ° thread_union 结构 的 下 一 个 字 
段 为 thread_union 定义 如 下 : 


struct thread_info { 


struct task_struct *task; 

struct exec_domain *exec_domain; 

__u32 flags; 

__u32 status; 

u32 cpu; 

int saved_preempt_count; 


mm_segment_t addr_limit; 


struct restart_block restart_block; 
void __user *sysenter_return; 
unsigned int sig_on_uaccess_error:1; 


unsigned int uaccess_err:1; 


此 结构 占用 52 个 字 节 。 thread_info 结构 包含 了 特定 体系 架构 相关 的 线程 信息 ， 我 们 都 知道 
在 x86_64 架构 上 内 核 栈 是 逆 生成 而 thread_union.thread_info 结构 则 是 正 生 长 。 所 以 进程 进 
程 栈 是 16KB 并 且 thread_info 是 在 栈 底 。 还 需 我 们 处 理 16 kilobytes - 62 bytes = 16332 
bytes .注意 thread_union 代表 一 个 联合 体 union 而 不 是 双 吉 构 体 ， 用 一 张 图 来 描 述 栈 内 存 空 

间 。 如 下 图 所 示 : 


Stack 





a 





thread_info 


http://www.quora.com/In-Linux-kernel-Why-thread_info-structure-and-the-kernel-stack-of-a- 
process-binds-in-union-construct 


所 以 INIT TASK 宏 指令 就 是 task_struct's ' 结 构 。 正 如 我 上 述 所 写 ， 我 并 不 会 去 描述 这 些 字段 
的 含义 和 值 ， 在 INIT Task 赋值 处 理 的 时 候 我 们 很 快 能 看 到 这 些 。 


现在 让 我 们 回 到 set_task_stack_end_magic 函数， 这 个 函数 被 定义 在 kernel/fork.c 功 能 为 设 
置 canary init 进程 堆栈 以 检测 堆栈 溢出 。 





void set_task_stack_end_magic(struct task_struct *tsk) 


{ 

unsigned long *stackend; 

stackend = end_of_stack(tsk); 

*stackend = STACK_END_MAGIC; /* for overflow detection */ 
} 


上 述 函 数 比 较 简 单 ” set_task_stack_end_magic 函数 的 作用 是 先 通 过 end_of_stack 函数 获取 
堆栈 并 赋 给 task_struct ° 关于 检测 配置 需要 打开 内 核 配 置 宏 CONFIG STACK_GROWSUP ° 因为 
我 们 学 习 的 是 x86 架 构 的 初始 化 ， 堆 栈 是 逆 生 成 ， 所 以 堆栈 底部 为 : 





(unsigned long *)(task thread info(p) + 1); 


task_thread_info 的 定义 如 下 ， 返 回 一 个 当前 的 堆栈 ; 


#define task_thread_info(task) ((struct thread_info *)(task)->stack) 


进程 的 栈 底 ， 我 们 写 STACK_END_MAGIC 这 个 值 。 如 果 设 置 canary ， 我 们 可 以 像 这 样子 去 检测 
堆栈 : 


if (*end_of_stack(task) != STACK_END_MAGIC) { 
ia 
// handle stack overflow here 
// 


set_task_stack_end_magic 初始 化 完毕 后 的 下 一 个 函数 是 smp_setup_processor_id .此 函数 
在 x86_64 RW LE BHR: 





void _ init _ weak smp_setup_processor_id(void) 
{ 
} 


在 此 架构 上 没有 实现 此 函数 ， 但 在 别 的 体系 架构 的 实现 可 以 参考 s390 and arm64. 


我 们 接着 往 下 走 ， 下 一 个 函数 是 debug_objects_early_init 。 此 函数 的 执行 几乎 
和 lockdep_init 是 一 样 的 ， 但 是 十 充 的 哈 希 对 象 是 调试 相关 。 上 述 我 已 经 表明 ， 关 于 内 核 调 
试 部 分 会 在 后 续 专门 有 一 个 章节 来 完成 。 


debug_object_early_init 函数 之 后 我 们 看 到 调用 水 boot_init_stack_canary f 

数 。 task_struct->canary 的 值 利用 了 GCC 特性 ， 但 是 此 特性 需要 先 使 能 

核 CONFIG_CC_STACKPROTECTOR 宏 后 才 可 以 使 用 。 poot_init_stack_canary 什么 也 没有 做 ， 否 
则 基于 随机 数 和 随机 池 产 生 TSC: 





get_random_bytes(&canary, sizeof(canary)); 
tsc = native_read_tsc(); 





canary += tsc + (tsc << 32UL); 


我 们 要 获取 随机 数 , 我 们 可 以 给 stack_canary 字段 task_struct 赋值 : 


current->stack_canary = canary; 


然后 将 此 值 写 入 IRQ 堆 栈 的 顶部 : 


this_cpu_write(irq_stack_union.stack_canary, canary); // read below about this_ cpu_ wri 
Ee 


关于 IRQ 的 章节 我 们 这 里 也 不 会 详细 刨 析 , 关于 这 部 分 介绍 看 这 里 |RQs. 如 果 canary 被 设置 , 关 
闭 本 地 中 断 注册 bootstrap CPU 以 及 CPU maps. 我 们 关闭 本 地 中 断 (interrupts for current 
CPU) 使 用 local irq disable 43° RAGIRAA arch_local_irq_disable $ 
%include/linux/percpu-defs.h: 


static inline notrace void arch_local_irgq_enable(void) 


{ 


native_irq_enable(); 


如 果 native_irq_enable 通过 cli 指令 判断 架构 ， 这 里 是 x86 64 > Where 
native_irq_enable is cli instruction for x86_64 .中 断 的 关闭 (屏蔽 ) 我 们 可 以 通过 注册 当前 
CPU ID 到 CPU bitmap 来 实现 。 


激活 第 一 个 CPU 


当前 已 经 走 到 start_kernel BAP áJ boot_cpu_init 函数 ， 此 函数 主要 为 了 通过 扼 码 初始 化 
每 一 个 CPU。 首 先 我 们 需要 获取 当前 处 理 器 的 ID 通过 下 面子 数 : 


int cpu = smp_processor_id(); 


现在 是 0. 如 果 CONFIG_DEBUG_PREEMPT 宏 配 置 了 那么 smp_processor_id 的 值 就 来 自 于 
raw_smp_processor_id 函数 ， 原型 如 下 : 


#define raw_smp_processor_id() (this_cpu_read(cpu_number ) ) 


this_cpu_read 函数 与 其 它 很 多 Hy IX — AF he ( this_cpu_write , this_cpu_add FF...) 被 定义 
#éinclude/linux/percpu-defs.h 此 部 分 函数 主要 为 对 this_cpu 进行 操作 . 这 些 操作 提供 不 同 的 
对 每 cpuper-cpu 变量 相关 访问 方式 . 壁 如 让 我 们 来 看 看 这 个 函数 this_cpu_read : 


pcpu_size_call_return(this_cpu_read_, pcp) 





还 记得 上 面 我 们 所 写 ， 每 cpu 变 量 cpu_number 的 值 是 this_cpu_read Ñ 
过 raw_smp_processor_id 来 得 到 ， 现 在 让 我 们 看 看 pcpu_size_call_return 的 执行 : 








#define pcpu_size_call_return(stem, variable) 


({ 


typeof(variable) pscr_ret__; 





verify_pcpu_ptr(&(variable)); 

switch(sizeof(variable)) { 

case 1: pscr_ret__ = stem##1(variable); break; 
case 2: pscr_ret__ = stem##2(variable); break; 
case 4: pscr_ret__ = stem##4(variable); break; 
case 8: pscr_ret__ = stem##8(variable); break; 
default: 

bad_size_call_parameter(); break; 





} 


pscr_ret__; 


a oe oo CC ed eC ee 


t) 


A) > tb ha BRA AA Re EY KML ce fe] BAY > RAAF pscr_ret ”变量 的 定义 
F 


a 


int 类 型 ， 为 ee > 变量 是 common_cpu 它 声明 了 每 cpu(per-cpu) 变 量 : 


DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number); 





在 下 一 个 步骤 中 我 们 调用 了 __verify_pcpu_ptr 通过 使 用 一 个 有 效 的 每 cpu 变 量 指针 来 取 地 址 
得 到 cpu_number ° 之 后 我 们 通过 ret_ ”函数 设置 变量 的 大 小 ， common _cpu 变量 

是 int ,所 以 它 的 大 小 是 4 字 节 。 意 思 就 是 我 们 通过 this_cpu_read_4(common_cpu) 获取 cpu 变 量 
其 大 小 被 pscr_ret 决定 。 在 pcpu size call return 的 结束 我 们 调用 了 

_ pcpu_size_call_return : 








#define this_cpu_read_4(pcp) percpu_from_op("mov", pcp) 


需要 调用 percpu_from_op 并 且 通 过 mov 指令 来 传递 每 cpu 变 量 ” percpu_from_op 的 内 联 扩展 
如 下 : 


asm( "movl %%gs:%1,%0" : "=r" (pfo_ret__) : "m" (common_cpu) ) 


oe 试 理解 此 函数 是 如 果 工 作 的 ， gs 段 寄存 器 包含 每 个 CPU 区 域 的 初始 值 ， 这 里 我 们 通 
mov 指令 copy common_cpu 到 内 存 中 去 ， 此 函数 还 有 另外 的 形式 : 


this_cpu_read(common_cpu) 
等 价 于 : 


movl %gs:$common_cpu, $pfo_ret__ 


由 于 我 们 没有 设置 每 个 CPU 的 区 域 ,我 们 只 有 一 个 -为 当前 CPU 的 值 zero 通过 此 函数 
smp_processor_id 返回 . 


返回 的 ID 表示 我 们 处 于 哪 一 个 CPU 上 ，boot_cpu_init BAKA T CPUE R, 激活 , 当前 的 设 
置 为 : 


set_cpu_online(cpu, true); 
set_cpu_active(cpu, true); 
set_cpu_present(cpu, true); 
set_cpu_possible(cpu, true); 


上 述 我 们 所 有 使 用 的 这 些 CPU 的 配置 我 们 称 之 为 - CPU 掩 码 cpumask . cpu_possible 则 是 设 

置 支持 CPU 热 插 拔 时 候 的 CPU ID. cpu_present 表示 当前 热 插 拔 的 CPU.，cpu_online 表示 当 

前 所 有 在 线 的 CPU 以 及 通过 cpu_present 来 决定 被 调度 出 去 的 CPU. CPU 热 插 拔 的 操作 需要 

打开 内 核 配置 宏 CONFIG_HoTPLuG_cpu 并 且 将 possible == present 以 及 active == online 选 

项 禁用 。 这 些 功 能 都 非常 相似 ， 每 个 函数 都 需要 检查 第 二 个 参数 ， 如 果 设 置 为 true ， 需 要 通 
过 调用 cpumask_set_cpu Of cpumask_clear_cpu 来 改变 状态 。 


壁 如 我 们 可 以 通过 true 或 者 第 二 个 参数 来 这 么 调用 : 


cpumask_set_cpu(cpu, to_cpumask(cpu_possible_bits)); 


让 我 们 继续 尝试 理解 to_cpumask 宏 指 令 ， 此 宏 指 令 转 化 为 一 个 位 图 通过 struct cpumask * ， 
CPU 掩 码 提 供 了 位 图 集 代 表 了 当前 系统 中 所 有 的 CPU's， 每 CPU 都 占用 1bit，CPU 掩 码 相 关 定 
义 通过 cpu_mask 结构 定义 : 


typedef struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t; 


在 来 看 下 面 一 组 函数 定义 了 位 图 宏 指令 。 


#define DECLARE_BITMAP(name, bits) unsigned long name[BITS_TO_LONGS(bits) ] 


正如 我 们 看 到 的 定义 一 样 ， DECLARE BITMAP 宏 指令 的 原型 是 一 个 unsigned long 的 数组 ， 现 
在 让 我 们 查看 如 何 执 行 to_cpumask : 


#define to_cpumask(bitmap) \ 
((struct cpumask *)(1 ? (bitmap) \ 
: (void *)sizeof(__check_is_bitmap(bitmap) ))) 


我 不 知道 你 是 怎么 想 的 , 但 是 我 是 这 么 想 的 ， 我 看 到 此 函数 其 实 就 是 一 个 条 件 判 断 语句 当 条 件 
A BAIS 4R > (2 AH AMT _check_is_bitmap ?让 我 们 看 看 _check is bitmap 的 定义 : 


static inline int __check_is_bitmap(const unsigned long *bitmap) 


{ 


return 2; 


} 


原来 此 函数 始终 返回 1， 事 实 上 我 们 需要 这 样 的 函数 才 达 到 我 们 的 目的 : 它 在 编译 时 给 定 一 
AN bitmap ， ae ag EREE bitmap 的 类 型 是 否 是 unsigned long * ,因此 我 们 仅仅 通 

过 to_cpumask 宏 指令 将 类 型 为 unsigned long 的 数组 转化 为 struct cpumask * 。 现 在 我 们 可 
以 调用 cpumask_set_cpu 函数 ， 这 个 函数 仅仅 是 一 个 set_bit 给 CPU 掩 码 的 功能 函数 。 所 有 
的 这 些 set_cpu_* 函数 的 原理 都 是 一 样 的 。 


如 果 你 还 不 确定 set_cpu_* 这 些 函 数 的 操作 并 且 不 能 理解 cpumask 的 概念 ， 不 要 担心 。 你 可 
以 通过 读 取 这 些 章节 cpumask or documentation. 来 继续 了 解 和 学 习 这 些 函数 的 原理 。 


现在 我 们 已 经 激活 第 一 个 CPU， 我 们 继续 接着 start_kernel 有 函数 往 下 走 ， 下 面 的 函数 
是 page_address_init ,但 是 此 函数 不 执行 任何 操作 ， 因 为 只 有 当 所 有 内 存 不 能 直接 映射 的 时 候 
才 会 执行 。 


Linux 内 核 的 第 一 条 打印 信息 
F 74 fl F pr_notice Až ° 


#define pr_notice(fmt, ...) \ 
printk(KERN_NOTICE pr_fmt(fmt), ## VA ARGS ) 


pr_notice 其 实 是 printk 的 扩展 ， 这 里 我 们 使 用 它 打 印 了 Linux 的 banner。 
pr_notice("%s", linux_banner) ; 
打印 的 是 内 核 的 版 本 号 以 及 编译 环境 信息 : 


Linux version 4.0.0-rc6+ (alex@localhost) (gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6) 
) #319 SMP 


依赖 于 体系 结构 的 初始 化 部 分 


下 个 步骤 我 们 就 要 进入 到 指定 的 体系 架构 的 初始 函数 ，Linux 内 核 初始 化 体系 架构 相关 调 
用 setup_arch 函数 ， 这 又 是 一 个 类 型 于 start_kernel 的 庞大 函数 ， 这 里 我 们 仅仅 简单 描述 ， 
在 下 一 个 章节 我 们 将 继续 深入 。 指 定 体系 架构 的 内 容 ， 我 们 需要 再 一 次 阅读 arch/ 目 


录 ， setup_arch 函数 定义 在 arch/x86/kernel/setup.c 文件 中 ， 此 函数 就 一 个 参数 -内 核 命 令 


a 
o 


此 函数 解析 内 核 的 段 text 和 _data RAT _text 符号 和 _bss_stop (你 应 该 还 记得 此 文件 
arch/x86/kernel/head 64.S)。 我 们 使 用 memblock 来 解析 内 存 块 。 


memblock_reserve(__pa_symbol(_text), (unsigned long)__bss_stop - (unsigned long)_text) 


你 可 以 阅读 关于 memblock 的 相关 内 容 在 Linux kernel memory management Part 1.， 你 应 该 
还 记得 memblock_reserve 函数 的 两 个 参数 : 


e base physical address of a memory block; 
e size of amemory block. 


我 们 可 以 通过 _pa_symbol 宏 指 令 来 获取 符号 表 _text 段 中 的 物理 地 址 


#define __pa_symbol(x) \ 
__phys_addr_symbol(__phys_reloc_hide((unsigned long)(x))) 


上 述 宏 指令 调用 _ phys_reloc_hide 宏 指令 来 填充 参数 ， __phys_reloc_hide % BAGS 
在 X86_64 上 返回 的 参数 是 给 定 的 。 宏 指令 _ phys_addr_symbol 的 执行 是 简单 的 ， 只 是 减 去 
从 _text 符号 表 中 读 到 的 内 核 的 符号 映射 地 址 并 且 加 上 物理 地 址 的 基地 址 。 


#define __phys_addr_symbol(x) \ 
( (unsigned long)(x) - START_KERNEL_map + phys_base) 





memblock_reserve 函数 对 内 存 页 进行 分 配 。 


保留 可 用 内 存 初 始 化 initrd 


之 后 我 们 保留 替换 内 核 的 text 和 data 段 用 来 初始 化 initrd, 我 们 暂时 不 去 了 解 initrd 的 详细 信息 ， 
你 仅仅 只 需要 知道 根 文 件 系统 就 是 通过 这 方式 来 进行 初始 化 这 就 是 early_reserve_initrd 函 
数 的 工作 ， 此 函数 获取 RAM DISK 的 基地 址 以 及 大 小 以 及 大 小 加 偏 移 。 


u64 ramdisk_image = get_ramdisk_image(); 
u64 ramdisk_size = get_ramdisk_size(); 
u64 ramdisk_end = PAGE_ALIGN(ramdisk_image + ramdisk_size); 


如 果 你 阅读 过 这 些 章 节 Linux Kernel Booting Process， 你 就 知道 所 有 的 这 些 啊 参数 都 来 自 
于 boot_params ， 时 刻 谨 记 boot_params 在 boot 期 间 已 经 被 赋值 ， 内 核 启 动 关 包 含 了 一 下 几 个 
字段 用 来 描述 RAM DISK : 


Field name: ramdisk_image 


Type: write (obligatory) 
Offset/size: 0x218/4 
Protocol: 2.00+ 


The 32-bit linear address of the initial ramdisk or ramfs. Leave at 
zero if there is no initial ramdisk/ramfs. 


我 们 可 以 得 到 关于 boot_params 的 一 些 信息 . 具体 查看 get_ramdisk_image : 


static u64 _ init get_ramdisk_image(void) 


{ 
u64 ramdisk_image = boot_params.hdr.ramdisk_image; 
ramdisk_image |= (u64)boot_params.ext_ramdisk_image << 32; 
return ramdisk_image; 

} 


关于 32 位 的 ramdisk 的 地 址 ， 我 们 可 以 阅读 此 部 分 内 容 来 获取 Documentation/x86/zero- 
page. txt: 


0C0/004 ALL ext_ramdisk_image ramdisk_image high 32bits 
32 位 变 ， 我 们 获取 64 位 的 ramdisk 原 理 一 样 ， 为 此 我 们 可 以 检查 bootloader 提供 的 
ae a ; 


if (!boot_params.hdr.type_of_loader || 
!'ramdisk_image || !ramdisk_size) 


return; 


并 保留 内 存 块 将 ramdisk 传 输 到 最 终 的 内 存 地 址 ， 然 后 进行 初始 化 : 


memblock_reserve(ramdisk_image, ramdisk_end - ramdisk_image); 


结束 语 


以 上 就 是 第 四 部 分 关于 内 核 初 始 化 的 部 分 内 容 ， 我 们 从 start_kernel 函数 开始 一 直到 指定 体 
系 架 构 初 始 化 setup_arch 的 过 程 中 停止 ， 那 么 在 下 一 个 章节 我 们 将 继续 研究 体系 架构 相关 的 


初始 化 内 容 。 
如 果 你 有 任何 的 问题 或 者 建议 ， 你 可 以 留言 ， 也 可 以 直接 发 消息 给 我 twitter 。 


内 核 入 口 - start_kernel 


很 抱歉 ， 英 语 并 不 是 我 的 母 的 ， 非 常 抱 菊 给 您 阅读 带 来 不 便 ， 如 果 你 发 现 文中 描述 有 任何 问 
题 ， 请 提交 一 个 PR 到 linux-insides. 


链接 


e GCC function attributes 
e this_cpu operations 

e cpumask 

e lock validator 

e cgroups 

e stack buffer overflow 

e IRQs 

e initrd 

e Previous part 


内 核 初 始 化 第 五 部 分 


与 系统 架构 有 关 的 初始 化 后 续 分 析 


在 之 前 的 章节 中 ， 我 们 讲 到 了 与 系统 架构 有 关 的 setup_arch 函数 部 分 ， 本 文 会 继续 从 这 里 开 
始 。 我 们 为 initrd 预 留 了 内 存 之 后 ， 下 一 步 是 执行 olpc_ofw detect 函数 检测 系统 是 否 支 持 

One Laptop Per Child support。 我 们 不 会 考虑 与 平台 有 关 的 东西 ， 且 会 忽略 与 平台 有 关 的 兄 
数 。 所 以 我 们 继续 往 下 看 。 下 一 步 是 执行 early_trap_init 函数 。 这 个 函数 会 初始 化 调试 功 
能 ( #DB - 当 TF 标志 位 和 rflags 被 设置 时 会 被 使 用 ) 和 ints ( wep ) 中 断 门 。 如 果 你 不 
了 解 中 断 ， 你 可 以 从 初期 中 断 和 异常 处 理 中 学 习 有 关中 断 的 内 容 。 在 x86 架构 

P > Int >? INTO 和 INT3 是 支持 任务 显 式 调 用 中 断 处 理 函 数 的 特殊 指令 。 ints 指令 调用 

断 点 ( #BP ) 处 理 函 数 。 你 如 果 记得 ， 我 们 在 这 部 分 看 到 过 中 断 和 蜡 党 概念 : 


|3 | #BP |Breakpoint |Trap |NO |INT 3 


调试 中 断 #DB 是 激活 调试 器 的 重要 方法 。 early_trap_init 函数 的 定义 在 
arch/x86/kernel/traps.c 中 。 这 个 函数 用 来 设置 #DB 和 #BP 处 理 函 数 ， 并 且 实 现 重 新 加 载 
IDT ° 


void Minit early_trap_init(void) 

{ 
set_intr_gate_ist(X86_TRAP_DB, &debug, DEBUG_STACK); 
set_system_intr_gate_ist(X86_TRAP_BP, &int3, DEBUG_STACK); 
load_idt(&idt_descr); 





我 们 之 前 中 断 相 关 章 节 中 看 到 过 set_intr_gate 的 实现 。 这 里 的 set_intr_gate_ist 和 
set_system_intr_gate_ist 也 是 类 似 的 实现 。 这 两 个 函数 都 需要 三 个 参数 : 





e 中 断 号 
o 中 断 /异常 处 理 函 数 的 基地 址 
e 第 三 个 参数 是 Interrupt Stack Table ° IST Æ TSS 的 部 分 内 容 ， 是 x86 64 引入 的 


新 机 制 。 在 内 核 态 处 于 活路 状态 的 线程 拥有 16kb 的 内 核 栈 空间 。 但 是 在 用 户 空 间 的 线 
程 的 内 核 栈 是 空 的 。 除了 线程 栈 ， a cpu 有 关 的 特殊 栈 。 你 可 以 查阅 
linux 内 核 文 档 - Kernel stacks 部 分 了 解 这 些 栈 信息 。 x86_64 提供 了 像 在 非 屏 获 中断 等 
类 似 事件 中 切换 新 的 特殊 栈 的 特性 支持 。 这 个 特性 的 名 字 是 Interrupt Stack Table ° 每 
个 CPU 最 多 可 以 有 7 个 IST 条 目 ， 每 个 条 目 有 自己 特定 的 栈 。 在 我 们 的 案例 中 使 用 的 
是 DEBUG_STACK ° 


set_intr_gate_ist 和 set system_intr_gate_ist 与 set_intr_gate 的 工作 原理 几乎 一 样 ? 
只 有 一 个 区 别 。 这 些 函 数 检查 中 断 号 并 在 内 部 调用 _set_gate 





BUG_ON((unsigned)n > OxFF); 
_set_gate(n, GATE_INTERRUPT, addr, ©, ist, __KERNEL_CS); 


其 中 ， set_intr_gate 把 dpl 和 ist 置 为 0 来 调用 _set gate ° {22 set_intr_gate_ist 
和 set_system intr_gate ist 把 ist 设置 为 DEBUG STACK ， 并 且 
set_system_intr_gate_ist 把 dpl 设置 为 优先 级 最 低 的 gx3 。 当中 断 发 生 时 ， 硬 件 加 载 这 
个 描述 符 ， 然 后 硬件 根据 IST 的 值 自动 设置 新 的 栈 指针 。 之 后 激活 对 应 的 中 断 处 理 函 数 。 
所 有 的 特殊 内 核 栈 会 在 cpu_init 函数 中 设置 好 (我 们 会 在 后 文中 提 到 ) 。 








4 #DB 和 wep 门 向 idt_descr 有 写 操作 ， 我 们 会 调用 load_ idt 函数 来 执行 ldtr 指令 
来 重新 加 载 mT Keo 现在 我 们 来 了 解 下 中 断 处理 函 数 并 尝试 理解 它 的 工作 原理 。 当 然 ， 我 
们 不 可 能 在 这 本 书 中 讲解 所 有 的 中 断 处 理 函 数 。 深 入 学 习 linux 的 内 核 源 码 是 很 有 意思 的 事 
情 ， 我 们 会 在 这 里 讲解 debug 处 理 函 数 的 实现 。 请 自行 学 习 其 他 的 中 断 处 理 函 数 实现 。 


HDB 2b FE Ha 


像 上 文中 提 到 的 ， 我 们 在 set_intr_gate_ist 中 通过 adebug 的 地 址 传送 #DB 处 理子 

数 。|xr.free-electorns.com 是 很 好 的 用 来 搜索 linux 源 代 码 中 标识 符 的 资源 。 遗憾 的 是 ， 你 在 
其 中 找 不 到 debug AE HA o HRA arch/x86/include/asm/traps.h 中 找到 debug 的 定 

ar 


asmlinkage void debug(void); 


从 asmlinkage 属性 我 们 可 以 知道 debug 是 由 assembly 语言 实现 的 函数 。 是 的 ， 又 是 汇编 
语言 :)。 和 其 他 处 理 函 数 一 样 ，#DB 处 理 函 数 的 实现 可 以 在 arch/x86/kernel/entry 64.S X 
件 中 找到 。 都 是 由 idtentry 汇编 宏 定 义 的 : 


idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK 


idtentry 是 一 个 定义 中 断 /异常 指令 入 口 点 的 宏 。 它 需要 五 个 参数 : 


中 断 条 目 点 的 名 字 

e 中 断 处 理 函 数 的 名 字 

是 否 有 中 断 错误 码 

© paranoid - 如 果 这 个 参数 置 为 1， 则 切换 到 特殊 栈 
e shift_ist - 支持 中 断 期 间 切 换 栈 


现在 我 们 来 看 下 idtentry 宏 的 实现 。 这 个 宏 的 定义 也 在 相同 的 汇编 文件 中 ， 并 且 定 义 了 有 
ENTRY 宏 属 性 的 debug 函数 。 首先 ， idtentry 宏 检 查 所 有 的 参数 是 否 正 确 ， 是否 需要 切 
换 到 特殊 栈 。 接 下 来 检查 中 断 返 回 的 错误 码 。 例 如 本 案例 中 的 #DB 不 会 返回 错误 码 。 如 果 
有 错误 码 返 回 ， 它 会 调用 INTR_FRAME 或 者 XCPT_FRAM 宏 。 其 实 xcpT_FRAME 和 

INTR_FRAME 宏 什么 也 不 会 做 ， Sn ed 。 它们 使 用 cer 指令 用 
来 调试 。 你 可 以 查阅 更 多 有 关 cer 指令 的 信息 CFI- 就 像 arch/x86/kernel/entry_64.S 中 解 
释 : cer 宏 是 用 来 产生 更 好 的 回溯 的 dwarf2 的 解 开 信息 。 它们 不 会 改变 任何 代码 。 因 此 
我 们 可 以 忽略 它们 。 


,macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 
ENTRY(\sym) 

/* Sanity check */ 

.if \shift_ist != -1 && \paranoid == 0 

.error "using shift_ist requires paranoid=i" 

.endif 


.if \has_error_code 
XCPT_FRAME 

.else 

INTR_FRAME 

.endif 


当中 断 发 生 后 经 过 初期 的 中 断 /异常 处 理 ， 我 们 可 以 知道 栈 内 的 格式 是 这 样 的 : 


EEEE + 
l | 
+40 | SS | 
+32 | RSP | 
+24 | RFLAGS | 
+16 | CS | 
+8 | RIP | 
9 | Error Code | <---- rsp 
| | 
ET + 


idtentry 实现 中 的 另外 两 个 宏 分 别 是 


ASM_CLAC 
PARAVIRT_ADJUST_EXCEPTION_FRAME 


第 一 个 AsM_cLAc 宏 依 赖 于 coNFIG_x86_sMAP 这 个 配置 项 和 考虑 安全 因素 ， 你 可 以 从 这 里 了 
解 更 多 内 容 。 第 二 个 PARAVIRT EXCEPTION_FRAME 宏 是 用 来 处 理 xen 类 型 异常 (这 章 只 讲解 
内 核 初 始 化 ， 不 会 考虑 虚拟 化 的 内 容 ) 。 下 一 段 代 码 会 检查 中 断 是 否 有 错误 码 。 如 果 没 有 则 


会 把 $-1 (在 x86 64 架构 下 值 为 ”gxffffffffffffffff EAR : 


.ifeq \has_error_code 
pushq_cfi $-1 
.endif 


为 了 保证 对 于 所 有 中 断 的 栈 的 一 致 性 ， 我 们 会 把 它 处 理 为 dummy 错误 码 。 下 一 步 我 们 从 栈 指 
4t F RHA $ORIG_RAX-R15 


subq $ORIG_RAX-R15, %rsp 


其 中 ，oRIG_RAX ， R15 和 其 他 宏 都 定义 在 arch/x86/include/asm/calling.h P ° oRTG_RAX- 
R15 是 120 字 节 。 我 们 在 中 断 处理 过 程 中 需要 把 所 有 的 寄存 器 信息 存储 在 栈 中 ， 所 有 通用 寄 
存 器 会 占用 这 个 120 字 节 。 为 通用 寄存 器 设置 完 栈 之 后 ， 下 一 步 是 检查 从 用 户 空间 产生 的 中 
wT: 


testl $3, CS(%rsp) 
jnz 1f 


我 们 查看 段 寄 存 器 cs 的 前 两 个 比特 位 。 你 应 该 记得 cs 寄存 器 包含 段 选择 器 ， 它 的 前 两 个 
比特 是 RPL 。 所 有 的 权限 等 级 是 0-3 范 围 内 的 整数 。 数 字 越 小 代表 权限 越 高 。 因 此 当中 断 来 

自 内 核 空间 ， 我 们 会 调用 save_paranoid ， 如 果 不 来 自 内 核 空 间 ， 我 们 会 跳 转 到 标签 1 处 处 
理 。 在 save paranoid 函数 中 ， 我 们 会 把 所 有 的 通用 寄存 器 存储 到 栈 中 ， 如 果 需 要 的 话 会 用 

PR gs 切换 到 内 核 态 gs 


movl $1,%ebx 
movl $MSR_GS_BASE, %ecx 
rdmsr 
testl %edx, %edx 
js if 
SWAPGS 
xorl %ebx, %ebx 
abe ret 


下 一 步 我 们 把 pt_regs 指针 存在 rdi 中 ， 如 果 存 在 错误 码 就 把 它 存储 到 rsi 中 ， 然 后 调 
用 中 断 处 理 函 数 ， 例 如 就 像 arch/x86/kernel/trap.c 中 的 do_debug ° do debug 像 其 他 处 理光 
数 一 样 需要 两 个 参数 : 


e pt regs - 是 一 个 存储 在 进程 内 存 区 域 的 一 组 CPU 寄存 器 
e error code - 中 断 错误 码 


中 断 处 理 函数 完成 工作 后 会 调用 paranoid_exit 还 原 栈 区 。 如 果 中 断 来 自用 户 空 间 则 切换 回 
用 户 态 并 调用 iret 。 我 们 会 在 不 同 的 章节 继续 深入 分 析 中 断 。 这 是 用 在 #DB 中 断 中 的 
idtentry 宏 的 基本 介绍 所 有 的 中 断 都 和 这 个 实现 类 似 都 定义 在 

idtentry 中 ° early_trap_init 执行 完 后 ， 下 一 个 函数 是 early_cpu_init ° 这 个 函数 定义 
在 arch/x86/kernel/cpu/common.c 中 ， 负 责 收 集 cpu 和 其 供应 商 的 信息 。 


早期 ioremap 初 始 化 


下 一 步 是 初始 化 早期 的 ioremap 。 通 常 有 两 种 实现 与 设备 通信 的 方式 : 


e |/ 〇 端口 


。 设备 内 存 


我 们 在 linux 内 核 启 动 过 程 中 见 过 第 一 种 方法 (通过 outb/inb 指令 实现 ) 。 第 二 种 方法 是 把 
I/0 的 物理 地 址 映射 到 虚拟 地 址 。 当 cpu 读 取 一 段 物理 地 址 时 ， 它 可 以 读 取 到 映射 了 1/0 
设备 的 物理 RAM 区 域 。 ioremap 就 是 用 来 把 设备 内 存 映 射 到 内 核 地 址 空间 的 。 


像 我 上 面 提 到 的 下 一 个 函数 时 early_ioremap_init ， 它 可 以 在 正常 的 像 ioremap 这 样 的 映射 
函数 可 用 之 前 ， 把 I/0 内 存 映射 到 内 核 地 址 空间 以 方便 读 取 。 我 们 需要 在 初期 的 初始 化 代 
码 中 初始 化 临时 的 ioremap 来 映射 1/0 设备 到 内 存 区 域 。 初 期 的 ioremap 实现 在 
arch/x86/mm/ioremap.c 中 可 以 找到 。 在 early ioremap_init 的 一 开始 我 们 可 以 看 到 

pmd_t 类 型 的 pmd 指针 定义 (代表 页 中 间 目录 条 目 typedef struct {pmdval_t pmd; } 
pmd_t; 其 中 pmdval_t 是 无 符号 长 整 型 ) 。 然后 检查 fixmap 是 正确 对 齐 的 : 


pmd_t *pmd; 
BUILD_BUG_ON((fix_to_virt(9) + PAGE_SIZE) & ((1 << PMD_SHIFT) - 1)); 


fixmap - 是 一 段 从 FIXADDR_START 到 FIXADDR_TOP 的 国定 庶 拟 地 址 映射 区 域 。 它 在 子 系统 
需要 知道 虚拟 地 址 的 编译 过 程 中 会 被 使 用 。 之 后 early_ioremap_init 函数 会 调用 
mm/early_ioremap.c 中 的 early_ioremap_setup 函数 。 early_ioremap_setup 会 填充 512 个 
临时 的 尼 动 时 国定 映射 表 来 完成 无 符号 长 整 型 矩阵 slot_virt 的 初始 化 : 


for (i = 0; i < FIX_BTMAPS_SLOTS; i++) 
slot_virt[i] = __fix_to_virt(FIX_BTMAP_BEGIN - NR_FIX_BTMAPS*i); 


之 后 我 们 就 获得 了 FIX_BTMAP_BEGIN 的 页 中 间 目 录 条 目 ， 并 把 它 赋值 给 了 pmd 变量 ， 把 局 
动 时 间 页 表 bm_pte 写 满 0。 然 后 调用 pmd_populate_kernel Kk Be eg HL 中 间 目 录 的 
页 表 条 目 : 


pmd = early_ioremap_pmd(fix_to_virt(FIX_BTMAP_BEGIN) ); 
memset(bm_pte, 0, sizeof(bm_pte)); 
pmd_populate_kernel(&init_mm, pmd, bm_pte); 


这 就 是 所 有 过 程 。 如 果 你 仍然 觉得 困惑 ， 不 要 担心 。 在 内 核 内 存 管理 ， 第 二 部 分 章节 会 有 单 


独 一 部 分 讲解 ioremap 和 fixmaps ° 


获取 根 设 备 的 主 次 设备 号 
ioremap 初始 化 完成 后 ， 紧 接着 是 执行 下 面 的 代码 : 


ROOT_DEV = old_decode_dev(boot_params.hdr.root_dev); 


这 段 代 码 用 来 获取 根 设 备 的 主 次 设备 号 。 后 面 initrd 会 通过 do_mount_root MAcdt HF EX 
个 根 设备 上 。 其 中 主 设备 号 用 来 识别 和 这 个 设备 有 关 的 驱动 。 次 设备 号 用 来 表示 使 用 该 驱动 
的 各 设备 。 注 意 old decode dev 函数 是 从 boot_params_structure 中 获取 了 一 个 参数 。 我 们 
可 以 从 x86 linux 内 核 启 动 协议 中 查 到 : 


Field name: root_dev 

Type: modify (optional) 
Offset/size: Oxifc/2 
Protocol: ALL 


The default root device device number. The use of this field is 
deprecated, use the "root=" option on the command line instead 


现在 我 们 来 看 看 old_decode dev 如 何 实现 的 。 实 际 上 它 只 是 根据 主 次 设备 号 调用 了 MKDEV 
来 生成 一 个 dev t 类 型 的 设备 。 它 的 实现 很 简单 : 


static inline dev t old_decode_dev(u16 val) 


{ 
return MKDEV((val >> 8) & 255, val & 255); 


其 中 devt 是 用 来 表示 主 /次 设备 号 对 的 一 个 内 核 数据 类 型 。 但 是 这 个 奇怪 的 old 前 级 代表 
了 什么 呢 ? 出 于 历史 原因 ， 有 两 种 管理 主 次 设备 号 的 方法 。 第 一 种 方法 主 次 设备 号 占用 2 字 
。 你 可 以 在 以 前 的 代码 中 发 现 : 主 设备 号 占用 8 bit， 次 设备 号 占用 8 bit。 但 是 这 会 引入 一 


个 问题 : 最 多 只 能 支持 256 个 主 设备 号 和 256 个 次 设备 号 。 因此 后 来 引入 了 32 bit KATE 
次 设备 号 ， 其 中 12 位 用 来 表示 主 设备 号 ，20 位 用 来 表示 次 设备 号 。 你 可 以 在 
new_decode_dev 的 实现 中 找到 : 


static inline dev_t new_decode_dev(u32 dev) 

{ 
unsigned major = (dev & Oxfff00) >> 8; 
unsigned minor = (dev & Oxff) | ((dev >> 12) & Oxfff00); 
return MKDEV(major, minor); 


如 果 dev 的 值 是 gxffffffff ， 经 过 计算 我 们 可 以 得 到 用 来 表示 主 设 备 号 的 12 位 值 
goxfff ， 表 示 次 设备 号 的 20 位 值 gxfffff 。 因 此 经 过 old decode dev 我 们 最 终 可 以 得 到 在 
ROOT_DEV 中 根 设 备 的 主 次 设备 号 。 


Memory Map 人 设置 


下 一 步 是 调用 setup_memory_map 函数 设置 内 存 映射 。 但 是 在 这 之 前 我 们 需要 设置 与 显示 屏 有 
关 的 参数 〈 目 前 有 行 、 列 ， 视 频 页 等 ， 你 可 以 在 显示 模式 初始 化 和 进入 保护 模式 中 了 解 ) > 
与 拓展 显示 识别 数据 ， 视 频 模 式 ， 引 导 局 动 器 类 Bes 参数 : 


screen_info = boot_params.screen_info; 
edid_info = boot_params.edid_info; 
saved_video_mode = boot_params.hdr.vid_mode; 
bootloader_type = boot_params.hdr.type_of_loader; 
if ((bootloader_type >> 4) == Oxe) { 
bootloader_type &= Oxf; 
bootloader_type |= (boot_params.hdr.ext_loader_typet+0x10) << 4; 


} 
bootloader_version = bootloader_type & Oxf; 
bootloader_version |= boot_params.hdr.ext_loader_ver << 4; 


我 们 可 以 从 启动 时 候 存储 在 boot_params 结构 中 获取 这 些 参 数 信息 。 之 后 我 们 需要 设置 1/0 
内 存 。 众 所 周知 ， 内 核 主 要 做 的 工作 就 是 资源 管理 。 其 中 一 个 资源 就 是 内 存 。 我 们 也 知道 目 
前 有 通过 I/0 口 和 设备 内 存 两 种 方法 实现 设备 通信 。 所 有 有 关注 册 资 源 的 信息 可 以 通过 
/proc/ioports 和 /proc/iomem 获得 : 


e /proc/ioports - 提供 用 于 设备 输入 输出 通信 的 一 租 注册 端口 区 域 
e /proc/iomem - 提供 每 个 物理 设备 的 系统 内 存 映 射 地 址 我 们 先 来 看 下 /proc/iomem 


cat /proc/iomem 
00000000-00000fF fF : reserved 
00001000-0009d7fF : System RAM 
0009d800-0009fF FFF : reserved 
000a0000-000bffff : PCI Bus 0000:00 
000c0000-000cffFF : Video ROM 
000d0000-000d3ffFF : PCI Bus 0000:00 
000d4000-000d7ffF : PCI Bus 0000:00 
000d8000-000dbfffF : PCI Bus 0000:00 
000dc000-000dffff : PCI Bus 0000:00 
000e0000-000fffff : reserved 
000e0000-000e3fFF : PCI Bus 0000:00 
000e4000-000e7ffFF : PCI Bus 0000:00 
000f0000-000fffTfTf : System ROM 


可 以 看 到 ， 根 据 不 同属 性 划分 为 以 十 六 进 制 符号 表示 的 一 段 地址 范围 。linux 内 核 提 供 了 用 来 
管理 所 有 资源 的 一 种 通用 API。 全 局 资源 (比如 PICS 或 者 10 端口 ) 可 以 划分 为 与 硬件 总 线 
4648 AKO FH ° resource 的 主要 结构 是 


struct resource { 
resource_size_t start; 
resource_size_t end; 
const char *name; 
unsigned long flags; 
struct resource *parent, *sibling, *child; 


}; 


例如 下 图 中 的 树 形 系 统 资源 子 集 示 例 。 这 个 结构 提供 了 资源 占用 的 从 start 到 end 的 地 址 
范围 ( resource_size_t 是 phys_addr_t 类 型 ， 在 X86_64 架构 上 是 u64 ) 。 资源 名 (你 
可 以 在 /proc/iomem 输出 中 看 到 ) ， 资 源 标 记 (所 有 的 资源 标记 定义 在 include/linux/ioport.h 
文件 中 ) 。 最 后 三 个 是 资源 结构 体 指 针 ， 如 下 图 所 示 : 


二 于 有 全 用 下 十 Toe + 
l | | | 
| parent |------ | sibling | 
| | | | 
二 站 本 本 二 全 号 号 三 三 忆 十 有 十 
| 
| 
十 
| | 
| child | 
| | 
十 


每 个 资源 子 集 有 自 己 的 根 范围 资源 ° iomem 的 资源 iomem_resource 的 定义 是 : 


struct resource iomem_resource = { 


.name = "PCI mem", 
.Start = 0, 
.end = -1, 


.flags = IORESOURCE_MEM, 
J; 
EXPORT_SYMBOL(iomem_resource); 
TODO EXPORT_SYMBOL 


iomem_resource 利用 pcr mem 名 字 和 IORESOURCE_MEM (0x00000200) 标记 定义 了 io AF 
的 根 地 址 范围 。 就 像 上 文 提 到 的 ， 我 们 目前 的 目的 是 设置 iomem 的 结束 地 址 ， 我 们 需要 这 样 
做 : 


iomem_resource.end = (iULL << boot_cpu_data.x86_phys_bits) - 1; 


我 们 对 1 左 移 boot_cpu_data.x86_phys_bits ° boot_cpu_data 是 我 们 在 执行 early_cpu_init 

的 时 候 初始 化 的 cpuinfo_xse 结构 。 从 字面 理解 ，x86_phys_bits 代表 系统 可 达到 的 最 大 内 
存 地 址 时 需要 的 比特 数 。 另外 ， iomem resource 是 通过 EXPORT_SYMBOL 宏 传 递 的 。 这 个 宏 

可 以 把 指定 的 符号 (例如 iomem_resource ) 做 动态 链接 。 换 名 话说 ， 它 可 以 支持 动态 加 载 模 
块 的 时 候 访 问 对 应 符号 。 设置 完 根 iomem 的 资源 地 址 范围 的 结束 地 址 后 ， 下 一 步 就 是 设置 

内 存 映 射 。 它 通过 调用 setup_memory_map HA EH, : 


void __init setup_memory_map(void) 


{ 
char *who; 
who = x86_init.resources.memory_setup(); 
memcpy(&e820_saved, &e820, sizeof(struct e820map)); 
printk(KERN_INFO "e820: BIOS-provided physical RAM map:\n"); 
e820_print_map(who); 

} 


首先 ， 我 们 来 看 下 x86_init.resources.memory_setup ° x86_init 是 一 种 x86_init_ops 类 型 
的 结构 体 ， 用 来 表示 项 资源 初始 化 ， pci 初始 化 平台 特定 的 一 些 设置 函数 。 x86_init 的 初 
始 化 实现 在 arch/x86/kernel/x86_init.c 文件 中 。 我 不 会 全 部 解释 这 个 初始 化 过 程 ， 因 为 我 们 只 


x 


关心 一 个 地 方 : 


struct x86_init_ops x86_init __initdata = { 


»Fesources 


=o 


. probe_roms 


»-reserve_resources 


.memory_setup 


}, 


我 们 可 以 看 到 ， 这 里 的 memory_setup 赋值 为 default_machine_specific_memory_setup ， 它 是 
我 们 在 对 内 核 启动 过 程 中 的 所 有 e820 条 目 经 过 整理 和 把 内 存 分 区 填 入 e826map 结构 体 中 获 
得 的 。 所 有 收集 的 内 存 分 区 会 用 printk 打印 出 来 。 你 可 以 通过 运行 dmesg 命令 找到 类 似 


于 下 面 的 信息 : 


. 000000] 
. 000000] 
. 000000] 
. 000000] 
. 000000] 
. 000000] 
. 000000] 
. 000000] 
. 000000] 
. 000000] 
. 000000] 
. 000000] 
. 000000] 
. 000000] 
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probe_roms, 


reserve_standard_io_resources, 


e820: BIOS-provided physical RAM map: 


BIOS-e820: 
BIOS-e820: 
BIOS-e820: 
BIOS-e820: 
BIOS-e820: 
BIOS-e820: 
BIOS-e820: 
BIOS-e820: 
BIOS-e820: 
BIOS-e820: 
BIOS-e820: 
BIOS-e820: 
BIOS-e820: 


[mem 
[mem 
[mem 
[mem 
[mem 
[mem 
[mem 
[mem 
[mem 
[mem 
[mem 
[mem 
[mem 


0x0000000000000000 -0x000000000009d7 FF ] 
0x000000000009d800 -0x000000000009FT FFF] 
0x00000000000e0000-0x00000000000fffff] 
0x0000000000100000 -0x00000000be825fff] 
0x00000000be826000-0x00000000be82cfff] 
0x00000000be82d000-0x00000000bf744fff] 
0x00000000bf745000-0x00000000bfff4fff] 
0x00000000bfff5000-0x00000000dc041fff] 
0x00000000dc042000-0x00000000dc0d2fff] 
0x00000000dc0d3000-0x00000000dc138fff] 
0x00000000dc139000-0x00000000dc27dfff] 
0x00000000dc27e000-0x00000000deffefff] 
0x00000000defff000-0x00000000deffffff] 


复制 pros 增强 磁盘 设备 信息 


下 面 两 部 是 通过 parse_setup_data 函数 解析 setup_data ， 并 且 把 pros 的 eop 信息 复制 
setup_data 是 内 核 启 动 关中 包含 的 字段 ， 我 们 可 以 在 x86 的 启动 协议 中 了 


到 安全 的 地 方 。 
解 : 


default_machine_specific_memory_setup, 


usable 
reserved 
reserved 
usable 
ACPI NVS 
usable 
reserved 
usable 
reserved 
usable 
ACPI NVS 
reserved 
usable 


Field name: setup_data 


Type: write (special) 
Offset/size: 0x250/8 
Protocol: 2.09+ 


The 64-bit physical pointer to NULL terminated single linked list of 
struct setup_data. This is used to define a more extensible boot 


parameters passing mechanism. 


KE KE 


它 用 来 存储 不 同类 型 的 设置 信息 ， 例 如 设备 树 blob ， EFI 设置 数据 等 等 。 第 二 步 是 从 
boot_params 结构 中 复制 我 们 在 arch/x86/boot/edd.c 中 Bros 的 ebb 信息 到 eda 结构 
中 。 


static inline void _ init copy_edd(void) 


{ 
memcpy(edd.mbr_signature, boot_params.edd_mbr_sig_buffer, 
sizeof(edd.mbr_signature) ); 
memcpy(edd.edd_info, boot_params.eddbuf, sizeof(edd.edd_info)); 
edd.mbr_signature_nr = boot_params.edd_mbr_sig_buf_entries; 
edd.edd_info_nr = boot_params.eddbuf_entries; 
} 


内 存 描 述 符 初 始 化 


下 一 步 是 在 初始 化 阶段 完成 内 存 描述 符 的 初始 化 。 我 们 知道 每 个 进程 都 有 自己 的 运行 内 存 地 

址 空间 。 通 过 调用 memory descriptor 可 以 看 到 这 些 特 殊 数据 结构 。 在 linux 内 核 源 码 中 内 
存 描述 符 是 用 mm_struct 结构 体 表示 的 ° mm_struct 包含 许多 不 同 的 与 进程 地 址 空间 有 关 的 
字段 ， 像 内 核 代 码 / 数 据 段 的 起 始 和 结束 地 址 ， brk 的 起 始 和 结束 ， 内 存 区 域 的 数量 ， 内 存 
区 域 列 表 等 。 这 些 结构 定义 在 includellinux/mm types.h 中 。 task_struct 结构 的 mm 和 
active_mm 字段 包含 了 每 个 进程 自己 的 内 存 描 述 符 。 我们 的 第 一 个 init 进程 也 有 自己 的 内 
存 描述 符 。 在 之 前 的 章节 我 们 看 到 过 通过 INIT_TASK 宏 实现 task_struct 的 部 分 初始 化 信 
自 。 


woe 


#define INIT_TASK(tsk) \ 
{ 


.mm = NULL, \ 
.active mm = &init_mm, \ 


mm 指向 进程 地 址 空间 ， active_mm 指向 像 内 核 线程 这 样子 不 存在 地 址 空间 的 有 效 地 址 空间 
(你 可 以 在 这 个 文档 中 了 解 更 多 内 容 ) 。 接 下 来 我 们 在 初始 化 阶段 完成 内 存 描 述 符 中 内 核 代 
码 段 ， 数 据 段 和 brk 段 的 初始 化 : 


init_mm.start_code = (unsigned long) _text; 
init_mm.end_code = (unsigned long) _etext; 
init_mm.end_data = (unsigned long) _edata; 
init_mm.brk = _brk_end; 


init_mm 是 初始 化 阶段 的 内 存 描述 符 定 义 : 


struct mm_struct init_mm = { 


.mm_rb = RB_ROOT, 
. pgd = swapper_pg_dir, 
.mm_users = ATOMIC_INIT(2), 
.mm_count = ATOMIC_INIT(1), 
.mmap_sem = __RWSEM_INITIALIZER(init_mm.mmap_sem), 
.page_table_lock = _ SPIN_LOCK_UNLOCKED(init_mm.page_table_lock), 
-mmlist = LIST_HEAD_INIT(init_mm.mmlist), 
INIT_MM_CONTEXT(init_mm) 
}; 
其 中 mm_rb 是 虚拟 内 存 区 域 的 红 结构 ，pgd 是 全 局 页 目录 的 指针 ， mm user 是 使 用 该 


nae 间 的 进程 数目 ， mm_count Eee mmap_sem 是 内 存 区 域 信号 量 。 在 初始 化 阶 
段 完 成 内 存 描述 符 的 设置 后 ， 下 一 步 是 通过 mpx_mm_init 完成 Intel 内 存 保 护 扩展 的 初始 
化 。 下 一 步 是 代码 /数据 / bss 资源 的 初始 化 : 


code_resource.start = __pa_symbol(_text); 
code_resource.end = __pa_symbol(_etext)-1; 
data_resource.start = __pa_symbol(_etext); 
data_resource.end = __pa_symbol(_edata) -1; 
bss_resource.start = __pa_symbol(__bss_start); 
bss_resource.end = __pa_symbol(__bss_stop)-1; 


通过 上 面 我 们 已 经 知道 了 一 小 部 分 关于 resource 结构 体 的 样子 。 在 这 里 ， 我 们 把 物理 地 址 
段 赋值 给 代码 /数据 / bss 段 。 你 可 以 在 /proc/iomem 中 看 到 


00100000-be825fff : System RAM 
01000000-015bb392 : Kernel code 
015bb393-01930c3f : Kernel data 
01a11000-O1ac3fff : Kernel bss 
在 [arch/x86/kernel/setup.c](https://github.com/torvalds/linux/blob/16f73eb02d7e1765cca 
b3d2018e0bd98eb93d973/arch/x86/kernel/setup.c) 中 有 所 有 这 些 结构 体 的 定义 : 
static struct resource code_resource = { 


.name = "Kernel code", 

.Start = 0, 

.end = 0, 

.flags = IORESOURCE_BUSY | IORESOURCE_MEM 


}; 


本 章节 涉及 的 最 后 一 部 分 就 是 NX 配置 。 NX-bit 或 者 no-execute 位 是 页 目录 条 目的 第 63 
比特 位 。 它 的 作用 是 控制 被 映射 的 物理 页 面 是否 具 有 执行 代码 的 能 力 。 这 个 比特 位 只 会 在 通 
过 把 EFER.NXE 置 为 1 使 能 no-execute 页 保护 机 制 的 时 候 被 使 用 /设置 。 在 

x86_configure_nx 函数 中 会 检查 CPU 是 否 支 持 NX-bit ， 以 及 是 否 被 禁用 。 经 过 检查 后 ， 
我 们 会 根据 结果 给 _supported_pte_mask 赋值 : 


void x86_configure_nx(void) 


{ 
if (cpu_has_nx && !disable_nx) 
__supported_pte_mask |= _PAGE_NX; 
elise 
__supported_pte_mask &= ~_PAGE_NX; 
} 
结论 


以 上 是 linux 内 核 初 始 化 过 程 的 第 五 部 分 。 在 这 一 章 我 们 讲解 了 有 关 架 构 初 始 化 的 
setup_arch 哆 数 。 内 容 很 多 ， 但 是 我 们 还 没有 学 习 完 。 其 中 ， setup_arch 是 一 个 很 复杂 的 
函数 ， 共 至 我 不 确定 我 们 能 在 以 后 的 章节 中 讲 完 它 的 所 有 内 容 。 在 这 一 音节 中 有 一 些 很 有 站 
的 概念 像 Fix-mapped 地 址 ， ioremap 等 等 。 如 果 没 听 明 白 也 不 用 担心 ， 在 内 核 内 存 管理 ， 
第 二 部 分 还 会 有 更 详细 的 解释 。 在 下 一 章节 我 们 会 继续 讲解 有 关 结 构 初 始 化 的 东西 ， 以 及 初 
期 内 核 参数 的 解析 ， pi 设备 的 早期 转 存 ， 直 接 媒体 接口 扫描 等 等 。 


如 果 你 有 任何 问题 或 者 建议 ， 你 可 以 留言 ， 也 可 以 直接 发 送 消息 给 我 twitter 。 


很 抱歉， 英语 并 不 是 我 的 母语 ， 非 常 抱歉 给 您 阅读 带 来 不 便 ， 如 果 你 发 现 文 中 描述 有 任何 问 
题 ， 清 提交 一 个 PR 到 linux-insides。 


& 


pEi 


体系 架构 初始 化 


e mm vs active_mm 

e e820 

e Supervisor mode access prevention 
e Kernel stacks 

e TSS 

e IDT 

e Memory mapped I/O 

e CFI directives 

e PDF. dwarf4 specification 
e Call stack 

e 内 核 初始 化 . Part 4. 
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内 核 初 始 化 第 六 部 分 


仍旧 是 与 系统 架构 有 关 的 初始 化 


在 之 前 的 章节 我 们 从 arch/x86/kernel/setup.c 了 解 了 特定 于 系统 架构 的 初始 化 事务 (在 我 们 的 
例子 中 是 x86_64 架构 )， 并 且 通 过 x86_configure_nx 函数 根据 对 NX bit 的 支持 配置 了 
_PAGE_NX 标志 位 。 正如 我 之 前 写 的 ， setup_arch 函数 和 start_kernel 都 非常 复杂 ， 所 以 在 
这 个 和 下 个 章节 我 们 将 继续 学 习 关 于 系统 架构 初始 化 进程 的 内 容 。 x86_configure_nx 函数 的 
下 面 是 parse_early_param 函数 。 这 个 函数 定义 在 init/main.c 中 并 且 你 可 以 从 它 的 名 字 中 了 
解 到 ， 这 个 函数 解析 内 核 命令 行 并 且 基 于 给 定 的 参数 创建 不 同 的 服务 (所 有 的 内 核 命 令 行 参数 
你 都 可 以 在 Documentation/kernel-parameters.txt 找到 )。 你 可 能 记得 在 最 前 面 的 章节 我 们 
是 怎样 创建 earlyprintk 地 。 在 前 面 我 们 用 arch/x86/boot/cmdline.c 里 面 的 
cmdline_find_option 和 __cmdline_find_option ，_ cmdline_find_option_bool 函数 的 帮助 下 
寻找 内 核 参 数 及 其 值 。 我 们 在 通用 内 核 部 分 不 依赖 于 特定 的 系统 架构 ， 在 这 里 我 们 使 用 另 一 
种 方法 。 如 果 你 正在 阅读 linux 内 核 源 代码 ， 你 可 能 注意 到 这 样 的 调用 : 


early_param("gbpages", parse_direct_gbpages_on); 


early_param 宏 需 要 两 个 参数 : 

o 命令 行 参数 的 名 称 

e 如 果 给 定 的 参数 通过 ， 函 数 将 被 调用 
函数 定义 如 下 : 


#define early_param(str, fn) \ 
__setup_param(str, fn, fn, 1) 


这 个 定义 可 以 在 includel/linux/init.h 中 可 以 找到 . 
正如 你 所 看 到 的 ， early_param 宏 只 是 调用 了 __setup_param Z: 


#define _ setup_param(str, unique_id, fn, early) \ 
static const char __setup_str_##unique_id[] __initconst \ 
__aligned(1) = str; \ 





static struct obs_kernel_param setup_##unique_id N 
__used __section(.init.setup) \ 
__attribute_ ((aligned((sizeof(long))))) N 


= { __setup_str_##unique_id, fn, early } 


这 个 宏 内 部 定义 了 str_*_id 变量 (这 里 的 * 取决 于 给 定 的 函数 名 称 )， 然 后 把 给 定 
的 命令 行 参数 赋值 给 这 个 变量 。 在 下 一 行 中 ， 我 们 可 以 看 到 定义 了 一 个 obs_kernel_param 类 
型 的 变量 __setup_ * ae 其 进行 初始 化 。 





六 


obs_kernel param 结构 体 定义 如 下 : 


struct obs_kernel_param { 
const char *str; 
int (*setup_func)(char *); 
int early; 


}; 


这 个 结构 体 包 含 三 个 字段 : 


© 内 核 参 数 的 名 称 
o 根据 不 同 的 参数 ， 选 取 对 应 的 处 理 函 数 
© 决定 参数 是 否 为 early 的 标记 位 


注意 __set_param 宏 定 义 有 __section(.init.setup) 属性 意味 着 所 有 __setup_str_ * 
都 将 被 放置 在 .init.setup 区 段 中 ， 此 外 正如 我 们 在 ee we 中 
看 到 的 ， .init.setup 区 段 被 放置 在 __setup_start 和 setup_end 之 间 : 


#define INIT_SETUP(initsetup_align) 
. = ALIGN(initsetup_align); 
VMLINUX_SYMBOL(__setup_start) = .; 
*(,init.setup) 
VMLINUX_SYMBOL(__setup_end) = 


Ce ee ere 


现在 我 们 知道 了 参数 是 怎样 定义 的 ， 让 我 们 一 起 回 到 parse_early_param 的 实现 上 来 : 


void __init parse_early_param(void) 
{ 
static int done __initdata; 
static char tmp_cmdline[COMMAND_LINE_SIZE] initdata; 





if (done) 
return; 


/* All fall through to do_early_param. */ 
stricpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE); 
parse_early_options(tmp_cmdline) ; 

done = 1; 


parse_early_param 哆 数 内 部 定义 了 两 个 静态 变量 。 首 先 第 一 个 变量 done 用 来 检查 
parse_early param 函数 是 否 已 经 被 调用 过 ， 第 二 个 变量 是 用 来 临时 存储 内 核 命令 行 的 。 然 后 
我 们 把 boot_command_line 的 值 赋值 给 刚刚 定义 的 临时 命令 行 变 量 中 ( tmp_cmdline ) 并 且 从 
相同 的 源 代码 文件 main.c 中 调用 parse_early_options 函数 。 parse_early_options 函数 从 
kernel/params.c 中 调用 parse_args 函数 ，parse_args 解析 传 入 的 命令 行 然 后 调用 
do_early_param žr ° do early param BA 从 _setup_start 循环 到 _ setup_end ， 如 
nl obs_kernel_param 实例 中 的 early 字段 值 为 1 ,就 调用 obs_kernel_param 中 的 第 
二 个 函数 setup_func ° 在 这 之 后 所 有 基于 早期 命令 行 参数 的 服 务 都 已 经 被 创建 ， 在 
parse_early_param 之 后 的 下 一 个 函数 调用 是 x86_report nx ° 正如 我 在 这 章 开 头 所 写 的 ， 
我 们 已 经 用 x86_configure_nx 函数 配置 了 NX-bit 位 。 接 下 来 我 们 使 用 
arch/x86/mm/setup_nx.c 中 的 x86_report_nx Bear ep wT Nx 的 信息 。 

意 x86_report_nx HAREE x86_configure_nx 函数 之 后 调用 ， 
parse_early_param 之 后 调用 。 答 案 很 简单 : 因为 内 核 支 持 noexec 参数 ， 所 以 我 们 一 定 在 
parse_early_param 调用 并 且 解 析 noexec 参数 之 后 才能 调用 x86_report_nx 


noexec [X86] 
On X86-32 available only on PAE configured kernels. 
// 在 X86-32 架 构 上 ， 仅 在 配置 PAE 的 内 核 上 可 用 。 
noexec=on: enable non-executable mappings (default) 
//noexec=on: 开 启 非 可 执行 文件 的 映射 (默认 ) 
noexec=off: disable non-executable mappings 
//noexec=off: 禁用 非 可 执行 文件 的 映射 


我 们 可 以 在 启动 的 时 候 看 到 : 


bootconsole 
NX (Execute Disable) protection: active 





SMBIOS 2.8 present. 


之 后 我 们 可 以 看 到 下 面 函 数 的 调用 : 


memblock_x86_reserve_range_setup_data(); 


这 个 函数 的 定义 也 在 arch/x86/kernel/setup.c 中 ， 然 后 这 个 函数 为 ”setup_data 重新 映射 内 存 
并 保留 内 存 块 (你 可 以 阅读 之 前 的 章节 了 解 关 于 setup_data 的 更 多 内 容 ， 你 也 可 以 在 Linux 
kernel memory management 中 阅读 到 关于 ioremap and memblock 的 更 多 内 容 )。 


接 下 来 我 们 来 看 看 下 面 的 条 件 语句 : 


if (acpi_mps_check()) { 
#ifdef CONFIG_X86_LOCAL_APIC 
disable_apic = 1; 
#endif 
setup_clear_cpu_cap(X86_FEATURE_APIC); 


acpi_mps_check 函数 来 自 于 arch/x86/kernel/acpi/boot.c ， 它 的 结果 取决 于 
CONFIG_X86_LOCAL_APIC 和 CONFIG_x86_MPPARSE 配置 选项 : 


int __init acpi_mps_check(void) 
{ 
#if defined(CONFIG_X86_LOCAL_APIC) && !defined(CONFIG_X86_MPPARSE ) 
/* mptable code is not built-in*/ 
if (acpi_disabled || acpi_noirgq) { 
printk(KERN_WARNING "MPS support code is not built-in.\n" 
"Using acpi=off or acpi=noirq or pci=noacpi " 
"may have problem\n"); 
return 1; 


#endif 
return 0; 


acpi_mps_check 函数 检查 内 置 的 MPS 又 称 多 重 处 理 器 规范 ) 表 。 如 果 设 置 了 
CONFIG_X86_LOCAL_APIC 但 未 设置 CONFIG_x86_MPPAARSE ， 而 且 传递 给 内 核 的 命令 行 选项 中 有 
acpi=off ` acpi=noirg 或 者 pci=noacpi HR? MBA acpi_mps_check 函数 就 会 输出 警告 信 
息 。 如 果 acpi_mps_check 返回 了 1， 这 就 表示 我 们 禁用 了 本 地 APIC ,而 且 
setup_clear_cpu_cap 宏 清除 了 当前 CPU 中 的 x86_FEATURE_APIC 位 。 (你 可 以 阅读 CPU 
masks 了 解 关于 CPU mask 的 更 多 内 容 )。 


早期 的 PCI 转 储 
接 下 来 我 们 通过 下 面 的 代码 来 续 储 PCL 设备 : 


#ifdef CONFIG_PCI 
If (pci_early_dump_regs) 
early_dump_pci_devices(); 
#endif 


变量 pci_early_dump_regs 定义 在 arch/x86/pci/common.c 中 ， 他 的 值 取 决 于 内 核 命 令 行 参 
数 : pci=earlydump 。 我 们 可 以 在 drivers/pci/pci.c 中 看 到 这 个 参数 的 定义 : 


early_param("pci", pci_setup); 


pci_setup 函数 取出 pci= 之 后 的 字符 串 ， 然 后 进行 解析 。 这 个 函数 调用 drivers/pci/pci.c 中 
用 weak 修饰 符 定义 的 pcibios_setup 函数 ， 并 且 每 种 架构 都 重 写 了 weak 修饰 过 的 郊 
数 。 例 如 ， x86_64 架构 上 的 该 函数 版 本 在 arch/x86/pci/common.c 中 : 


chan “inate perbioszsetup(chanr *str)) 4 


} else if (!strcmp(str, "earlydump")) { 
pci_early_dump_regs = 1; 
return NULL; 


如 果 我 们 设置 了 coNFIG_PCI 选项 ， 而 且 向 内 核 命令 行 传递 了 pcisearlydum #7 > AA 
arch/x86/pci/early.c 中 的 early_dump_pci_devices 函数 将 会 被 调用 。 这 个 函数 像 下 面 这 样 来 
检查 pci 参 数 noearly : 


if (!early_pci_allowed()) 
return; 


如 果 条 件 不 成 立 则 返回 。 每 个 PCI 域 可 以 承载 多 达 256 条 总 线 ， 并 且 每 条 总 线 可 以 承载 多 达 
32 个 设备 。 那 么 接 下 来 我 们 进入 下 面 的 循环 : 
for (bus = 0; bus < 256; bus++) { 


for (slot = 0; slot < 32; slot++) { 
for (func = 0; func < 8; func++) { 


然后 我 们 通过 read pci config BARKER pci 配置 。 


这 就 是 pci 加 载 的 全 部 过 程 了 。 我 们 在 这 里 不 会 深入 研究 pci 的 细节 ， 不 过 我 们 会 在 
Drivers/PCI 章节 看 到 更 多 的 细节 。 


内 存 解 析 的 完成 


在 early_dump_pci_devices 函数 后 面 ， 有 一 些 与 可 用 内 存 和 e820 相 关 的 函数 ， 其 中 e820 的 
相关 信息 我 们 在 内 核 安装 的 第 一 步 章节 中 整理 过 。 


/* update the e820_saved too */ 
e820_reserve_setup_data(); 
finish_e820_parsing(); 


e820_add_kernel_range(); 
trim_bios_range(void); 

max_pfn = e820_end_of_ram_pfn(); 
early_reserve_e820_mpc_new(); 


让 我 们 来 一 起 看 看 上 面 的 代码 。 正 如 你 所 看 到 的 ， 第 一 个 函数 是 e828_reserve_setup data ° 
这 个 函数 和 我 们 前 面 看 到 的 memblock_x86_reserve_range_setup_data 函数 做 的 事情 几乎 是 相 
同 的 ， 但 是 这 个 函数 同时 还 会 调用 e820_update_range 函数 ， 向 e820map 中 用 给 定 的 类 型 添 
加 新 的 区 域 ， 在 我 们 的 例子 中 ， 使 用 的 是 E829_RESERVED_KERN 类 型 。 接 下 来 的 函数 是 
finish_e820_parsing ,这 个 函数 使 用 sanitize_ e820 map 函数 对 e826map 进行 清理 。 除 了 这 
两 个 函数 之 外 ， 我 们 还 可 以 看 到 一 些 与 e820 有 关 的 函数 。 你 可 以 在 上 面 的 列表 中 看 到 这 些 函 
数 。 e826_add_kernel_range 函数 需要 内 核 开 始 和 结束 的 物理 地 址 : 


u64 start = __pa_symbol(_text); 
u64 size = __pa_symbol(_end) - start; 


函数 会 检查 在 e826map 中 被 标记 成 E826RAM 的 .text .data 和 .bss 区 段 ， 如 果 没 有 这 
些 区 段 ， 那 么 就 会 输出 错误 信 息 。 接 下 来 的 trm_bios_range 函数 把 e820Map 中 的 前 4096 个 
字 节 修改 为 E820_RESERVED 并 且 再 次 调用 函数 sanitize_es20_map 清理 e82gmap 。 在 这 之 后 
我 们 使 用 e826_end_of_ram_pfn 品 数 得 到 最 后 一 个 页 帧 的 编号 ， 每 个 内 存 页 面 都 有 一 个 唯一 
的 编号 - 页 帧 号 ， e820_end_of_ram_pfn 函数 调用 e820_end_pfn 函数 返回 最 大 的 页 面 帧 号 : 


unsigned long __init e820_end_of_ram_pfn(void) 
{ 
return e820_end_pfn(MAX_ARCH_PFN); 


e820_end_pfn 函数 读 取 特 定 于 系统 架构 的 最 大 页 帧 号 (对 于 x86 64 架构 来 说 MAX_ARCH_PFN 
是 gx460990999 )。 在 e820_end_pfn 函数 中 我 们 遍历 整个 e820 He HALE e826 中 是 
GA E826_RAM 或 者 E826_PRAM 类 型 条 目 ， 因 为 我 们 只 能 对 这 些 类 型 计算 页 面 帧 号 ， 然 后 我 
们 得 到 当前 e826 页 面 帧 的 基地 址 和 结束 地 址 ， 同 时 对 这 些 地 址 进行 检查 : 


for (i = 0; i < e820.nr_map; i++) { 
struct e820entry *ei = &e820.map[i]; 
unsigned long start_pfn; 
unsigned long end_pfn; 


if (ei->type != E820_RAM && ei->type != E820_PRAM) 
continue; 


start_pfn = ei->addr >> PAGE_SHIFT; 
end_pfn = (ei->addr + ei->size) >> PAGE_SHIFT; 


if (start_pfn >= limit_pfn) 
continue; 

if (end_pfn > limit_pfn) { 
last_pfn = limit_pfn; 
break; 


} 
if (end_pfn > last_pfn) 
last_pfn = end_pfn; 


if (last_pfn > max_arch_pfn) 
last_pfn = max_arch_pfn; 


printk(KERN_INFO "e820: last_pfn = %#1x max_arch_pfn = %#1x\n", 
last_pfn, max_arch_pfn); 
return last_pfn; 


接 下 来 我 们 检查 在 循环 中 得 到 的 last_pfn ， last_pfn 不 得 大 于 特定 于 系统 架构 的 最 大 页 帧 
号 (在 我 们 的 例子 中 是 x86_64 系统 架构 ), 然 后 输出 关于 最 大 页 帧 号 的 信息 ， 并 且 返 回 
last_pfn 。 我 们 可 以 在 dmesg 的 输出 中 看 到 1last_pfn 


[ 0.000000] e820: last_pfn = 0x41f000 max_arch_pfn = 0x400000000 


在 这 之 后 ， 我 们 计算 出 了 最 大 的 页 帧 号 ， 我 们 要 计算 max_lowpfn ,这 是 低 端 内 存 或 者 低 于 
第 一 个 4GB 中 的 最 大 页 面 帧 。 如 果 系 统 安装 了 超过 4GB 的 内 存 RAM ， max_lowpfn 将 会 

是 e820_end_of_low_ram pfn 函数 的 结果 ， 这 个 函数 和 e820_end_of_ram_pfn 相似 ， 但 是 有 
4GB 限 制 ， 换 名 话说 max_low_pfn 和 max pfn 的 值 是 一 样 的 : 





if (max_pfn > (1UL<<(32 - PAGE_SHIFT) )) 
max_low_pfn = e820_end_of_low_ram_pfn(); 
elise 





max_low_pfn = max_pfn; 


high_memory = (void *)__va(max_pfn * PAGE_SIZE - 1) + 1; 


接 下 来 我 们 通过 va ZH 高 端 内 存 (有 更 高 的 内 存 直 接 映射 上 界 ) 中 的 最 大 页 帧 号 ,并 且 这 
个 宏 会 根据 给 定 的 物理 内 存 返 回 一 个 虚拟 地 址 。 


桌面 管理 接口 


在 处 理 完 不 同 内 存 区 域 和 e826 楼 之 后 ， 接 下 来 就 该 收集 计算 机 的 相关 信息 了 。 我 们 将 用 下 
面 的 函数 收集 与 桌面 管理 接口 有 关 的 所 有 信息 : 


dmi_scan_machine(); 
dmi_memdev_walk(); 


首先 是 定义 在 drivers/firmware/dmi_scan.c 中 的 dmi_scan_machine WA ° Rh HAA 
System Management BIOS 结构 ， 并 从 中 提取 信息 。 这 里 有 两 种 方法 来 访问 smptos 表 : 第 
一 种 是 从 EFI 的 配置 表 获 得 指向 sMBI0S 表 的 指针 ; 第 二 种 是 扫描 oxFoooo 和 ox10000 地 
址 之 间 的 物理 内 存 。 让 我 们 一 起 看 看 第 二 种 方法 。 dmi_scan_machine 函数 通过 
dmi_early_remap 函数 将 oxfoooo 和 6x16666 之 间 的 内 存 重 新 映射 并 追加 到 


early_ioremap Jes 


void __init dmi_scan_machine(void) 


{ 
char __iomem *p, *q; 
char buf[32]; 


p = dmi_early_remap(9xFO000, 0x10000); 
if (p == NULL) 
goto error, 


然后 迭代 所 有 的 DMI 头 部 地 址 ， 并 且 查 找 sm 字符 串 : 


memset(buf, ©, 16); 
for (q = p; q < p + 0x10000; q += 16) { 
memcpy_fromio(buf + 16, q, 16); 
if (!dmi_smbios3_present(buf) || !dmi_present(buf)) { 
dmi_available = 1; 
dmi_early_unmap(p, 0x10000); 
goto out; 


} 
memcpy(buf, buf + 16, 16); 


_SM 字符 串 一 定 在 gogFgoggh 和 gxgogFFFFF 地 址 之 间 。 在 这 里 我 们 用 memcpy_fromio 函 
数 向 buf 里 面 拷贝 16 个 字 节 ， 这 个 函数 和 memcpy 函数 的 作用 是 一 样 的 。 然 后 对 这 个 缓冲 
区 ( buf ) 执行 dmi_smbios3_present 和 dmi_present Wao KH hE buf 的 前 4 个 字 
节 是 否 是 sm 字符 串 ， 并 且 获 得 sMBI0S 的 版 本 和 _pMI ”的 属性 例如 _pMI 的 结构 表 


是 
长 度 、 结 构 表 的 地 址 等 等 ... 在 其 中 的 一 个 函数 完成 之 后 ， 你 就 可 以 在 dmesg 的 输出 中 看 到 它 
运 


[ 0.000000] SMBIOS 2.7 present. 


[ 0.000000] DMI: Gigabyte Technology Co., Ltd. Z97X-UD5H-BK/Z97X-UD5H-BK, BIOS F6 0 
6/17/2014 


在 dmi_scan_machine 函数 的 最 后 ， 我 们 取消 之 前 映射 的 内 存 : 


dmi_early_unmap(p, 9x10000); 


第 二 个 函数 是 - dmi_memdev_walk 。 和 你 想 的 一 样 ， 这 个 函数 遍历 整个 内 存 设 备 。 让 我 们 一 起 
看 看 这 个 函数 : 


void _ init dmi_memdev_walk(void) 
{ 
if (!dmi_available) 
return; 
if (dmi_walk_early(count_mem_devices) == 0 && dmi_memdev_nr) { 


dmi_memdev = dmi_alloc(sizeof(*dmi_memdev) * dmi_memdev_nr); 
if (dmi_memdev) 
dmi_walk_early(save_mem_devices) ; 


这 个 函数 检查 DMI ETA AE dmi_scan_machine WA PS LT SER o HAR 
存在 dmi_available 变量 中 ) ， 然 后 使 用 dmi_walk _early 和 dmi_alloc 子 数 收集 内 存 设 备 的 
有 关 信 息 ,其 中 dmi alloc 的 定义 如 下 : 


#ifdef CONFIG_DMI 
RESERVE_BRK(dmi_alloc, 65536); 
#endif 


定义 在 arch/x86/include/asm/setup.h 中 的 RESERVE_BRK HAAA brk 段 中 预 留 给 定 大 小 的 


空间 : 


init_hypervisor_platform(); 
x86_init.resources.probe_roms(); 
insert_resource(&iomem_resource, &code_resource); 
insert_resource(&iomem_resource, &data_resource); 
insert_resource(&iomem_resource, &bss_resource); 
early_gart_iommu_check(); 


均衡 多 处 理 (SMP) 的 配置 


接 下 来 的 一 步 是 解析 SMP 的 配置 信息 。 我 们 调用 find_smp_config HARA MRI MEF > B 


个 函数 内 部 调用 另 一 个 函数 : 


static inline void find_smp_config(void) 


{ 


x86_init.mpparse.find_smp_config(); 


区 


在 函数 的 内 部 ， xg6_init.mpparse.find_smp_config 函数 就 是 arch/x86/kernel/mpparse.c 中 的 
default_find_smp_config HA °- RIWI) default_find_smp_config 函数 扫描 内 存 中 的 一 些 


区 域 来 寻找 smp 的 配置 信息 ,并 在 找到 它们 的 时 候 返 回 : 


if (smp_scan_config(®x0, 0x400) || 
smp_scan_config(639 * 0x400, 0x400) || 
smp_scan_config(9xFO000, 0x10000)) 
return, 


首先 smp_scan_config 函数 内 部 定义 了 一 些 变 量 : 


unsigned int *bp = phys_to_virt(base); 
struct mpf_intel *mpf; 


第 一 个 变量 是 我 们 用 来 扫描 sup 配置 的 内 存 区 域 的 虚拟 地 址 ; 第 二 个 变量 是 指向 
mpf_intel 结构 体 的 指针 。 让 我 们 一 起 试 着 去 理解 mpf_intel 是 什么 吧 。 所 有 的 信息 都 存储 
在 多 处 理 器 配置 数据 结构 中 。 mpf_intel 就 是 这 个 结构 ， 看 下 来 像 是 下 面 这 样 : 


struct mpf_intel { 
char signature[4]; 
unsigned int physptr; 
unsigned char length; 
unsigned char specification; 
unsigned char checksum; 
unsigned char feature1; 
unsigned char feature2; 
unsigned char feature3; 
unsigned char feature4; 
unsigned char feature5; 


}; 


正如 我 们 在 文档 中 看 到 的 那样 - 系统 BIOS 的 主要 功能 之 一 就 是 创建 MP 浮 点 型 指针 结构 和 MP 
CER o 而且 操作 系统 必须 可 以 访问 关于 多 处 理 器 配置 的 有 关 信 息 ， mpf_intel 中 存储 了 多 
处 理 器 配置 表 的 物理 地 址 (看 结构 体 的 第 二 个 变量 ), 然 后 ， smp_scan_config m 间 定 的 内 存 
区 域 中 循环 查找 MP floating pointer structure ° 3k 还 会 检查 当 前 字 节 是 否 指 向 

SMP 签名 ， 然 后 检查 签名 的 校 验 和 ， 并 且 检 查 循环 中 的 mpf->specification 的 值 是 1 还 是 
4( 这 个 值 只 能 是 1 或 者 是 4): 


while (length > 0) { 
if ((*bp == SMP_MAGIC_IDENT) && 
(mpf->length == 1) && 
!mpf_checksum( (unsigned char *)bp, 16) && 
((mpf->specification == 1) 
|| (mpf->specification == 4))) { 


mem = virt_to_phys(mpf); 

memblock_reserve(mem, sizeof(*mpf)); 

if (mpf->physptr) 
smp_reserve_memory(mpf ); 


如 果 搜 索 成 功 ， 就 调用 memblock_reserve 函数 保留 一 定 的 内 存 块 ， 并 且 为 多 处 理 器 配置 表 保 
留 物理 地 址 。 你 可 以 在 MultiProcessor Specification 中 找到 相关 的 文档 。 你 也 可 以 在 smp 的 
特定 章节 阅读 更 多 细节 。 


其 他 的 早期 内 存 初始 化 程序 


在 setup_arch 的 下 一 步 ， 我 们 可 以 看 到 early_alloc_pgt_buf 函数 的 调用 ,这 个 函数 在 早期 
阶段 分 配 页 表 缓 冲 区 。 页 表 缓 冲 区 将 被 放置 在 ork 区 段 中 。 让 我 们 一 起 看 看 这 个 功能 的 实 


现 : 
void __init early arroc pgt bDuf(vord) 
{ 
unsigned long tables = INIT_PGT_BUF_SIZE; 
phys_addr_t base; 
base = __pa(extend_brk(tables, PAGE_SIZE)); 
pgt_buf_start = base >> PAGE_SHIFT; 
pgt_buf_end = pgt_buf_start; 
pgt_buf_top = pgt_buf_start + (tables >> PAGE_SHIFT); 
} 


首先 这 个 函数 获得 页 表 缓 冲 区 的 大 小 ， 它 的 值 是 INIT_P6T_BUF_SIZE ， 这 个 值 在 目前 的 linux 
4.0 内 核 中 是 (6 * PAGE_SIZE) 。 因 为 我 们 已 经 得 到 了 页 表 缓 冲 区 的 大 小 ， 现 在 我 们 调用 
extend_brk 函数 并 且 传 入 两 个 参数 : size 和 align。 你 可 以 从 他 们 的 名 称 中 猜 到 ,这 个 函数 扩展 
brk 区 段 。 正 如 我 们 在 linux 内 核 链接 脚本 中 看 到 的 ， ork 区 段 在 内 存 中 的 位 置 恰好 就 在 
BSS 区 上段 后 面 : 


. = ALIGN(PAGE_SIZE); 
.brk : AT(ADDR(.brk) - LOAD_OFFSET) { 


__brk_base = .; 
. t= 64 * 1024; /* 64k alignment slop space */ 
*(.brk_reservation) /* areas brk users have reserved */ 


__brk_limit = .; 


我 们 也 可 以 使 用 readelf 工具 来 找到 它 : 


[25] -DSS NOBITS ffffffff8199d000 ©00d9d000 
00000000000b4000 0000000000000000 WA 9 9 4096 


[26] .brk NOBITS ffffffff81a51000 00d9d000 
0000000000026000 0000000000000000 WA 0 9 1 





之 后 我 们 用 pa 宏 得 到 了 新 的 brk 区 段 的 物理 地 址 ， 我 们 计算 页 表 缓 冲 区 的 基地 址 和 结 
地 址 。 因 为 我 们 之 前 已 经 创建 好 了 页 面 缓冲 区 ， 所 以 现在 我 们 使 用 reserve_brk 函数 为 brk 
区 段 保 留 内 存 块 : 


static void __init reserve_brk(void) 








{ 
if (_brk_end > _brk_start) 
memblock_reserve(__pa_symbol(_brk_start), 
brk_end - _brk_start); 
_brk_start = 0; 
} 


注意 在 reserve brk 的 最 后 ， 我 们 把 _brk_start 赋值 为 0, 因 为 在 这 之 后 我 们 不 会 再 为 brk 
分 配 内 存 了 ， 我 们 需要 使 用 cleanup_highmap 函数 来 释放 内 核 映 射 中 越界 的 内 存 区 域 。 请 记 
住 内 核 映射 是 ”START_KERNEL map 和 _end - text 或 者 level2 kernel pgt 对 内 核 

_text ` data 和 bss 区 上段 的 映射 。 在 clean_high_map 的 开始 部 分 我 们 定义 下 面 这 些 参数 : 





unsigned long vaddr = START_KERNEL_map; 

unsigned long end = roundup( (unsigned long)_end, PMD_SIZE) - 1; 
pmd_t *pmd = level2_kernel_pgt; 

pmd_t *last_pmd = pmd + PTRS_PER_PMD; 





现在 ， 因 为 我 们 已 经 定义 了 内 核 映 射 的 开始 和 结束 位 置 ， 所 以 我 们 在 循环 中 遍历 所 有 内 核 页 
中 间 目 录 条 目 , 并 且 清 除 不 在 _text 和 end 区 段 中 的 条 目 : 


for (; pmd < last_pmd; pmd++, vaddr += PMD_SIZE) { 
if (pmd_none(*pmd) ) 
continue; 
if (vaddr < (unsigned long) _text || vaddr > end) 
set_pmd(pmd, __pmd(0)); 


在 这 之 后 ， 我 们 使 用 memblock_set_current_limit (你 可 以 在 linux 内 存 管 理 第 二 章节 阅读 关 
于 memblock 的 更 多 内 容 ) HARA memblock 分 配 内 存 设置 一 个 界限 ， 这 个 界限 可 以 是 
ISA_END_ADDRESS 或 者 ox100000 ， 然 后 调用 memblock_x86_fill 函数 根据 e820 来 填充 
memblock 相关 信息 。 你 可 以 在 内 核 初始 化 的 时 候 看 到 这 个 函数 运行 的 结果 : 


MEMBLOCK configuration: 

memory size = 0x1lfff7ec00 reserved size = 0x1e30000 

memory.cnt = 0x3 

memory [0x0] [0x00000000001000 -Ox0000000009eF FF], Ox9e000 bytes flags: 0x0 
memory [0x1] [0x00000000100000-0x000000bffdffff], Oxbfee0000 bytes flags: 0x0 
memory [0x2] [0x00000100000000-0x0000023fffffff], 0x140000000 bytes flags: 0x0 


reserved.cnt = 0x3 
reserved[0x0] [0x0000000009f000-0x000000000fffff], 0x61000 bytes flags: 0x0 
reserved[0x1] [0x00000001000000-0x00000001a57fff], Oxa58000 bytes flags: 0x0 


reserved[0x2] [0x0000007ec89000-0x0000007fffffff], 0x1377000 bytes flags: 0x0 


除了 memblock_x86_fill 之 外 的 其 他 函数 还 有 : early_reserve_e820_mpc_new 函数 在 e820map 
中 为 多 处 理 器 规格 表 分 配额 外 的 楷 ， reserve_real mode - 用 于 保留 从 oxo 到 1M 的 低 端 内 存 
用 作 到 实 模 式 的 跳板 (用 于 重启 等 ...)， trim_platform memory_ranges Wack T ARIA 

0x20050000 , 0x20110000 等 地 址 开头 的 内 存 空 间 。 这 些 内 存 区 域 必 须 被 排除 在 外 ， 因 为 
Sandy Bridge 会 在 这 些 内 存 区 域 出 现 一 些 问 题 ， trim low memory_range 函数 用 于 保留 
memblock 中 的 前 4KB 页 面 ， init_mem_mapping HA Pe PAGE_OFFSET 处 重建 物理 内 存 的 
直接 映射 ，early_trap_pf_init 函数 用 于 建立 wr 处 理 函 数 (我 们 将 会 在 有 关中 断 的 章节 看 
到 它 )，setup_real_mode 哆 数 用 于 建立 到 实 模 式 代码 的 跳板 。 


这 就 是 本 章 的 全 部 内 容 了 。 您 可 能 注意 到 这 部 分 并 没有 包括 setup_arch PUPA BA (如 
early_gart_iommu_check ` Mtrr 的 初始 化 函数 等 ...)。 正 如 我 已 经 说 了 很 多 次 的 ，setup_arch 
函数 很 复杂 ，linux 内 核 也 很 复杂 。 这 就 是 为 什么 我 不 能 包括 linux 内 核 中 的 每 一 行 代码 。 我 认 
为 我 们 并 没有 错过 重要 的 东西 , 但 是 你 可 能 会 说 : 每 行 代码 都 很 重要 。 是 的 , 这 没 错 , 但 不 管 怎 
样 我 略 过 了 他 们 , 因为 我 认为 对 于 整个 linux 内 核 面 面 俱 到 是 不 现实 的 。 无 论 如 何 , 我 们 会 经 党 
复习 所 学 的 内 容 , 如 果 有 什么 不 熟悉 的 内 容 , 我 们 将 会 深入 研究 这 些 内 容 。 


结束 语 


这 里 是 linux 内 核 初 始 化 进程 第 六 章节 的 结尾 。 在 这 一 章节 中 ， 我 们 再 次 深入 研究 了 


setup_arch 哆 数 ， 然 而 这 是 个 很 长 的 部 分 ， 我 们 目前 还 没有 学 习 完 。 的 确 ，setup_arch 很 复 
杂 ， 和 希望 下 个 章节 将 会 是 这 个 函数 的 最 后 一 个 部 分 。。 


如 果 你 有 任何 的 疑问 或 者 建议 ， 你 可 以 留言 ， 也 可 以 直接 发 消息 给 我 twitter 。 


很 抱 菊 ， 美 语 并 不 是 我 的 母语 ， 非 常 抱 菊 给 您 阅读 带 来 不 便 ， 如 果 你 发 现 文中 描述 有 任何 问 


题 ， 请 提交 一 个 PR 到 linux-insides. 
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Kernel initialization. Part 7. 


The End of the architecture-specific 
initialization, almost... 


This is the seventh part of the Linux Kernel initialization process which covers insides of the 

setup_arch function from the arch/x86/kernel/setup.c. As you can know from the previous 
parts, the setup_arch function does some architecture-specific (in our case it is x86_ 64) 
initialization stuff like reserving memory for kernel code/data/bss, early scanning of the 
Desktop Management Interface, early dump of the PC! device and many many more. If you 
have read the previous part, you can remember that we've finished it at the 

setup_real_mode function. In the next step, as we set limit of the memblock to the all 
mapped pages, we can see the call of the setup_log_buf function from the 
kernel/printk/printk.c. 


The setup_log_buf function setups kernel cyclic buffer and its length depends on the 
CONFIG_LOG_BUF_SHIFT configuration option. As we can read from the documentation of the 
CONFIG_LOG_BUF_SHIFT it can be between 12 and 21 . In the insides, buffer defined as 

array of chars: 


#define __LOG_BUF_LEN (1 << CONFIG_LOG_BUF_SHIFT) 
static char log_buf [__LOG_BUF_LEN] aligned(LOG_ALIGN); 
static char *log_buf = __log_buf; 





Now let's look on the implementation of the setup_log_buf function. It starts with check that 
current buffer is empty (It must be empty, because we just setup it) and another check that it 
is early setup. If setup of the kernel log buffer is not early, we call the 1og_buf_add_cpu 
function which increase size of the buffer for every CPU: 


if (log_buf != __log_ buf) 
return; 


if (tearly && !new_log_buf_len) 


log_buf_add_cpu(); 


We will not research 10g _buf_add_cpu function, because as you can see in the setup_arch , 
we Call setup_log_buf as: 


setup_log_buf(1); 


where 1 means that it is early setup. In the next step we check new_log_buf_len variable 
which is updated length of the kernel log buffer and allocate new space for the buffer with 
the memblock_virt_alloc function for it, or just return. 


As kernel log buffer is ready, the next function is reserve_initrd . You can remember that 
we already called the early_reserve_initrd function in the fourth part of the Kernel 
initialization. Now, as we reconstructed direct memory mapping in the init_mem_mapping 
function, we need to move initrd into directly mapped memory. The reserve_initrd function 
starts from the definition of the base address and end address of the initrd and check that 

initrd is provided by a bootloader. All the same as what we saw in the 

early_reserve_initrd . But instead of the reserving place in the memblock area with the call 
of the memblock_reserve function, we get the mapped size of the direct memory area and 
check that the size of the initrd is not greater than this area with: 


mapped_size = memblock_mem_size(max_pfn_mapped); 
if (ramdisk_size >= (mapped_size>>1) ) 
panic("initrd too large to handle, " 
"disabling initrd (%lld needed, %lld available)\n", 
ramdisk_size, mapped_size>>1); 


You can see here that we call memblock_mem_size function and pass the max_pfn_mapped to 
it, where max_pfn_mapped contains the highest direct mapped page frame number. If you do 
not remember what is page frame number , explanation is simple: First 12 bits of the virtual 
address represent offset in the physical page or page frame. If we right-shift out 12 bits of 
the virtual address, we'll discard offset part and will get Page Frame Number . In the 
memblock_mem_size we go through the all memblock mem (not reserved) regions and 
calculates size of the mapped pages and return it to the mapped_size variable (see code 
above). As we got amount of the direct mapped memory, we check that size of the initrd 
is not greater than mapped pages. If it is greater we just call panic which halts the system 
and prints famous Kerne! panic message. In the next step we print information about the 
initrd size. We can see the result of this in the dmesg output: 


[9.000000] RAMDISK: [mem 0x36d20000-0x37687ffF] 


and relocate initrd to the direct mapping area with the relocate_initrd function. In the 
start of the relocate_initrd function we try to find a free area with the 
memblock_find_in_range function: 


relocated_ramdisk = memblock_find_in_range(0, PFN_PHYS(max_pfn_mapped), area_ size, PAG 
E_SIZE); 


if (!relocated_ramdisk) 
panic("Cannot find place for new RAMDISK of size %lld\n", 
ramdisk_size); 


The memblock_find_in_range function tries to find a free area in a given range, in our case 
from o to the maximum mapped physical address and size must equal to the aligned size 
of the initrd . If we didn't find a area with the given size, we call panic again. If all is 
good, we start to relocated RAM disk to the down of the directly mapped memory in the next 
step. 


In the end of the _reserve_initrd function, we free memblock memory which occupied by 
the ramdisk with the call of the: 


memblock_free(ramdisk_image, ramdisk_end - ramdisk_image) ; 


After we relocated initrd ramdisk image, the next function is vsmp_init from the 
arch/x86/kernel/vsmp_64.c. This function initializes support of the scalemp vsmp . As | 
already wrote in the previous parts, this chapter will not cover non-related xs6_64 
initialization parts (for example as the current or AcPI , etc.). So we will skip implementation 
of this for now and will back to it in the part which cover techniques of parallel computing. 


The next function is io_delay_init from the arch/x86/kernel/io_delay.c. This function allows 
to override default default I/O delay oxso port. We already saw I/O delay in the Last 
preparation before transition into protected mode, now let's look on the io_delay_init 
implementation: 


void _ init io_delay_init(void) 
{ 
if (!io0_delay_override) 
dmi_check_system(io_delay_Oxed_port_dmi_table); 





This function check io_delay_override variable and overrides I/O delay port if 

io_delay_override is set. We can set io_delay_override variably by passing io_delay 
option to the kernel command line. As we can read from the Documentation/kernel- 
parameters.txt, io_delay option is: 


io_delay= [X86] I/0 delay method 
0x80 
Standard port 0x80 based delay 
Oxed 
Alternate port Oxed based delay (needed on some systems) 
udelay 
Simple two microseconds delay 
none 
No delay 


We can see io_delay command line parameter setup with the early_param macro in the 
arch/x86/kernel/io_delay.c 


early_param("io_ delay", io_delay_param) ; 


More about early_param you can read in the previous part. So the io _delay_param function 
which setups io_delay_override variable will be called in the do_early_param function. 

io_delay_param function gets the argument of the io_delay kernel command line 
parameter and sets io_delay_type depends on it: 


static int __init io_delay_param(char *s) 
{ 
if (1s) 
return -EINVAL; 


if (!strcemp(s, "Ox80")) 

io_delay_type = CONFIG_IO_DELAY_TYPE_OX80; 
else mii (TS CrCMpCS Oxed 

io_delay_type = CONFIG_IO_DELAY_TYPE_OXED; 
else if (!strcemp(s, "“udelay")) 

io_delay_type = CONFIG_IO_DELAY_TYPE_UDELAY; 
else if (!strcmp(s, "none")) 

io_delay_type = CONFIG_IO_DELAY_TYPE_NONE; 














else 
return -EINVAL; 


io_delay_override = 1; 
return 0; 


The next functions are acpi_boot_table_init , early_acpi_boot_init and initmem_init 
after the io_delay_init , but as | wrote above we will not cover ACPI related stuff in this 


Linux Kernel initialization process chapter. 


Allocate area for DMA 


In the next step we need to allocate area for the Direct memory access with the 
dma_contiguous_reserve function which is defined in the drivers/base/dma-contiguous.c. 

DMA is a special mode when devices communicate with memory without CPU. Note that we 
pass one parameter - max_pfn_mapped << PAGE_SHIFT , to the dma_contiguous_reserve 
function and as you can understand from this expression, this is limit of the reserved 
memory. Let's look on the implementation of this function. It starts from the definition of the 


following variables: 


phys_addr_t selected_size ©; 


phys_addr_t selected_base 0; 
phys_addr_t selected_limit = limit; 
bool fixed = false; 


where first represents size in bytes of the reserved area, second is base address of the 
reserved area, third is end address of the reserved area and the last fixed parameter 
shows where to place reserved area. If fixed is 1 we just reserve area with the 

memblock_reserve , if itis o we allocate space with the kmemleak_alloc . In the next step we 
check size_cmdline variable and if it is not equal to -1 we fill all variables which you can 
see above with the values from the cma kernel command line parameter: 


if (size_cmdline != -1) { 


You can find in this source code file definition of the early parameter: 


early_param( "cma", early_cma); 


where cma is: 


cma=nn[MG]@[start[MG][-end[MG]]] 
[ARM, X86, KNL] 
Sets the size of kernel global memory area for 
contiguous memory allocations and optionally the 
placement constraint by the physical address range of 
memory allocations. A value of © disables CMA 
altogether. For more information, see 
include/linux/dma-contiguous.h 


If we will not pass cma option to the kernel command line, size_cmdline will be equal to 
-1 . In this way we need to calculate size of the reserved area which depends on the 
following kernel configuration options: 


© CONFIG_CMA_SIZE_SEL_MBYTES -size in megabytes, default global cma area, which is 





equal tO CMA_SIZE_MBYTES * SZ_1M OF CONFIG CMA SIZE MBYTES * 1M ; 





e CONFIG_CMA_SIZE_SEL_PERCENTAGE - percentage of total memory; 


© CONFIG_CMA_SIZE_SEL_MIN - use lower value; 





è CONFIG_CMA_SIZE_SEL_MAX - use higher value. 





As we calculated the size of the reserved area, we reserve area with the call of the 
dma_contiguous_reserve_area function which first of all calls: 


ret = cma_declare_contiguous(base, size, limit, ©, ©, fixed, res_cma); 


function. The cma_declare_contiguous reserves contiguous area from the given base 
address with given size. After we reserved area for the pma , next function is the 

memblock_find_dma_reserve . AS you can understand from its name, this function counts the 
reserved pages in the pma area. This part will not cover all details of the cma and oma , 
because they are big. We will see much more details in the special part in the Linux Kernel 
Memory management which covers contiguous memory allocators and areas. 


Initialization of the sparse memory 


The next step is the call of the function - x86_init.paging.pagetable_init . If you try to find 
this function in the linux kernel source code, in the end of your search, you will see the 
following macro: 


#define native_pagetable_init paging_init 


which expands as you can see to the call of the paging init function from the 
arch/x86/mm/init_64.c. The paging_init function initializes sparse memory and zone sizes. 
First of all what's zones and what is it sparsemem . The Sparsemem is a special foundation in 
the linux kernel memory manager which used to split memory area into different memory 
banks in the NUMA systems. Let's look on the implementation of the paginig_init function: 


void _ init paging_init(void) 

{ 
sparse_memory_present_with_active_regions(MAX_NUMNODES) ; 
sparse_init(); 


node_clear_state(9, N_MEMORY); 
if (N_MEMORY != N_NORMAL_MEMORY ) 
node_clear_state(9, N_NORMAL_MEMORY); 


zone_sizes_init(); 


As you can see there is call of the sparse_memory_present_with_active_regions function 
which records a memory area for every numa node to the array of the mem_section 
structure which contains a pointer to the structure of the array of struct page . The next 

sparse_init function allocates non-linear mem_section and mem_map . In the next step we 
clear state of the movable memory nodes and initialize sizes of Zones. Every numa node is 
divided into a number of pieces which are called - zones . SO, zone_sizes_init function 
from the arch/x86/mm/init.c initializes size of zones. 


Again, this part and next parts do not cover this theme in full details. There will be special 
part about numa . 


vsyscall mapping 


The next step after sparsemem initialization is setting of the trampoline cr4 features which 

must contain content of the cr4 Control register. First of all we need to check that current 

CPU has support of the cr4 register and if it has, we save its content to the 
trampoline_cr4_features which is storage for cr4 in the real mode: 


if (boot_cpu_data.cpuid_level >= 0) { 
mmu_cr4_features = __read_cr4(); 
if (trampoline_cr4_features) 
*trampoline_cr4_features = mmu_cr4_features; 


The next function which you can see is map_vsyscal from the arch/x86/kernel/vsyscall_ 64.c. 
This function maps memory space for vsyscalls and depends on 

CONFIG_X86_VSYSCALL_EMULATION kernel configuration option. Actually vsyscall is a special 
segment which provides fast access to the certain system calls like getcpu , etc. Let's look 
on implementation of this function: 


void __init map_vsyscall(void) 


{ 
extern char __vsyscall_page; 
unsigned long physaddr_vsyscall = __pa_symbol(&__vsyscall_page); 
if (vsyscall_mode != NONE) 
__set_fixmap(VSYSCALL_PAGE, physaddr_vsyscall, 
vsyscall_mode == NATIVE 
? PAGE_KERNEL_VSYSCALL 
: PAGE_KERNEL_VVAR) ; 
BUILD_BUG_ON( (unsigned long)__fix_to_virt(VSYSCALL_PAGE) != 
(unsigned long)VSYSCALL_ADDR); 
} 


In the beginning of the map_vsyscall we can see definition of two variables. The first is 
extern variable _ vsyscall_page . As a extern variable, it defined somewhere in other source 
code file. Actually we can see definition of the _ vsyscall_page in the 
arch/x86/kernel/vsyscall_emu_64.S. The _ vsyscall page symbol points to the aligned calls 
of the vsyscalls aS gettimeofday , etc.: 


.globl __vsyscall_page 

.balign PAGE_SIZE, Oxcc 

.type __vsyscall_page, @object 
__vsyscall_page: 


mov $_NR_gettimeofday, %rax 
syscall 
ret 


.balign 1024, Oxcc 
mov $_NR_time, %rax 
syscall 

ret 


The second variable is physaddr_vsyscall which just stores physical address of the 
__vsyscall_page symbol. In the next step we check the vsyscall_mode variable, and if it is 
not equal to None , itis EMULATE by default: 


static enum { EMULATE, NATIVE, NONE } vsyscall_mode = EMULATE; 


And after this check we can see the call of the _ set fixmap function which calls 
native_set_fixmap with the same parameters: 


void native_set_fixmap(enum fixed_addresses idx, unsigned long phys, pgprot_t flags) 


__native_set_fixmap(idx, pfn_pte(phys >> PAGE_SHIFT, flags)); 





} 
void __native_set_fixmap(enum fixed_addresses idx, pte_t pte) 
{ 
unsigned long address = __fix_to_virt(idx); 
if (idx >= end_of_fixed_addresses) { 
BUG(); 
return; 
} 
set_pte_vaddr(address, pte); 
fixmaps_set++; 
} 


Here we can see that native set fixmap makes value of Page Table Entry from the given 
physical address (physical address of the _ vsyscall page symbol in our case) and calls 
internal function - __native_set_fixmap . Internal function gets the virtual address of the 
given fixed_addresses index ( vSYSCALL_PAGE in our case) and checks that given index is 
not greater than end of the fix-mapped addresses. After this we set page table entry with the 
call of the set_pte_vaddr function and increase count of the fix-mapped addresses. And in 
the end of the map_vsyscall we check that virtual address of the vsyscALL_pace (which is 
first index in the fixed_addresses ) is not greater than vsyscALL_ADpR whichis -10UL << 20 
or ffffffffff600000 with the BUILD_BUG_ON macro: 


BUILD_BUG_ON( (unsigned long) __fix_to_virt(VSYSCALL_PAGE) != 
(unsigned long)VSYSCALL_ADDR); 


Now vsyscall area is inthe fix-mapped area. That's all about map_vsyscall , if you do not 
know anything about fix-mapped addresses, you can read Fix-Mapped Addresses and 
ioremap. We will see more about vsyscalls inthe vsyscalls and vdso part. 


Getting the SMP configuration 


You may remember how we made a search of the SMP configuration in the previous part. 
Now we need to get the smp configuration if we found it. For this we check 

smp_found_config variable which we setin the smp_scan_config function (read about it the 
previous part) and call the get_smp_config function: 


If (smp_found_config) 
get_smp_config(); 


The get_smp_config expands to the xs86_init.mpparse.default_get_smp_config function 
which is defined in the arch/x86/kernel/mpparse.c. This function defines a pointer to the 
multiprocessor floating pointer structure - mpf_intel (you can read about it in the previous 
part) and does some checks: 


struct mpf_intel *mpf = mpf_found; 


if (!mpf) 
return; 


if (acpi_lapic && early) 
return; 


Here we can see that multiprocessor configuration was found in the smp_scan_config 
function or just return from the function if not. The next check is acpi_lapic and early . 
And as we did this checks, we start to read the smp configuration. As we finished reading it, 
the next step is - prefill_possible_map function which makes preliminary filling of the 
possible CPU's cpumask (more about it you can read in the Introduction to the cpumasks). 


The rest of the setup_arch 


Here we are getting to the end of the setup_arch function. The rest of function of course is 
important, but details about these stuff will not will not be included in this part. We will just 
take a short look on these functions, because although they are important as | wrote above, 
but they cover non-generic kernel features related with the numa , smp , ACPI and APICs , 
etc. First of all, the next call of the init_apic_mappings function. As we can understand this 
function sets the address of the local APIC. The next is x86_io_apic_ops.init and this 
function initializes I/O APIC. Please note that we will see all details related with APIc in the 
chapter about interrupts and exceptions handling. In the next step we reserve standard I/O 
resources like DMA , TIMER , FPU , etc., with the call of the 

x86_init.resources.reserve_resources function. Following is mcheck_init function initializes 

Machine check Exception and the lastis register_refined_jiffies which registers jiffy 
(There will be separate chapter about timers in the kernel). 


So that's all. Finally we have finished with the big setup_arch function in this part. Of course 
as | already wrote many times, we did not see full details about this function, but do not 
worry about it. We will be back more than once to this function from different chapters for 
understanding how different platform-dependent parts are initialized. 


That's all, and now we can back to the start_kernel fromthe setup_arch . 


Back to the main.c 


As | wrote above, we have finished with the setup_arch function and now we can back to 
the start_kernel function from the init/main.c. As you may remember or saw yourself, 

start_kernel function as big as the setup_arch . So the couple of the next part will be 
dedicated to learning of this function. So, let's continue with it. After the setup_arch we can 
see the call of the mm_init_cpumask function. This function sets the coumask pointer to the 
memory descriptor cpumask . We can look on its implementation: 


static inline void n nit_cpumask(struct mm_struct *mm) 


{ 
#ifdef CONFIG_CPUMASK_OFFSTACK 


mm->cpu_vm_mask_var = &mm->cpumask_allocation; 
#endif 
cpumask_clear(mm->cpu_vm_mask_var); 


As you can see in the init/main.c, we pass memory descriptor of the init process to the 
mm_init_cpumask and depends on coNFIG_CPUMASK_OFFSTACK configuration option we clear 
TLB switch cpumask . 


In the next step we can see the call of the following function: 


setup_command_line(command_line); 


This function takes pointer to the kernel command line allocates a couple of buffers to store 
command line. We need a couple of buffers, because one buffer used for future reference 
and accessing to command line and one for parameter parsing. We will allocate space for 
the following buffers: 


e saved_command_line - will contain boot command line; 
e initcall_command_line - will contain boot command line. will be used in the 
do_initcall_level ; 


e static_command_line - will contain command line for parameters parsing. 


We will allocate space with the memblock_virt_alloc function. This function calls 
memblock_virt_alloc_try_nid which allocates boot memory block with memblock_reserve if 





slab is not available or uses kzalloc_node (more about it will be in the linux memory 
management chapter). The memblock_virt_alloc USES BOOTMEM_LOW_LIMIT (physical 


address of the (PAGE_OFFSET + 0x1000000) Value) and BOOTMEM_ALLOC_ACCESSIBLE (equal to 
the current value of the memblock.current_limit ) as minimum address of the memory region 
and maximum address of the memory region. 


Let's look on the implementation of the setup_command_line : 


static void _ init setup_command_line(char *command_line) 
{ 


saved_command_line = 

memblock_virt_alloc(strilen(boot_command_line) + 1, 0); 
initcall_command_line = 

memblock_virt_alloc(strien(boot_command_line) + 1, 0); 
static_command_line = memblock_virt_alloc(strlen(command_line) + 1, 0); 
strcpy(saved_command_line, boot_command_line); 
strcpy(static_command_line, command_line) ; 


Here we can see that we allocate space for the three buffers which will contain kernel 
command line for the different purposes (read above). And as we allocated space, we store 

boot_command_line inthe saved_command_line and command_line (kernel command line 
from the setup_arch ) to the static_command_line . 


The next function after the setup_command_line is the setup_nr_cpu_ids . This function 
setting nr_cpu_ids (number of CPUs) according to the last bitin the cpu_possible_mask 
(more about it you can read in the chapter describes coumasks concept). Let's look on its 
implementation: 


void _ init setup_nr_cpu_ids(void) 
{ 
nr_cpu_ids = find_last_bit(cpumask_bits(cpu_possible_mask),NR_CPUS) + 1; 


Here nr_cpu_ids represents number of CPUs, nr_cpus represents the maximum number 
of CPUs which we can set in configuration time: 
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Actually we need to call this function, because nr_cpus can be greater than actual amount 
of the CPUs in the your computer. Here we can see that we call find_last_bit function and 
pass two parameters to it: 


e cpu_possible_mask bits; 
e maximum number of CPUS. 


In the setup_arch we can find the call of the prefill_possible_map function which 
calculates and writes to the cpu_possible_mask actual number of the CPUs. We call the 

find_last_bit function which takes the address and maximum size to search and returns 
bit number of the first set bit. We passed cpu_possible_mask bits and maximum number of 
the CPUs. First of all the find_last_bit function splits given unsigned long address to the 
words: 


words = size / BITS_PER_LONG; 


where BITS_PER_LONG is 64 onthe xs6_64 . As we got amount of words in the given size of 
the search data, we need to check is given size does not contain partial words with the 
following check: 
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if (size & (BITS_PER_LONG-1)) { 
tmp = (addr[words] & (~OUL >> (BITS_PER_LONG 
- (size & (BITS_PER_LONG-1))))); 
if (tmp) 
goto found; 


if it contains partial word, we mask the last word and check it. If the last word is not Zero, it 
means that current word contains at least one set bit. We go to the found label: 


found: 
return words * BITS PER LONG + __fls(tmp); 


Here you can see _ fis function which returns last set bit in a given word with help of the 
bsr instruction: 


static inline unsigned long __fls(unsigned long word) 


{ 
asm("bsr %1,%0" 
: "=r" (word) 
"rm" (word)); 
return word; 
} 


The bsr instruction which scans the given operand for first bit set. If the last word is not 
partial we going through the all words in the given address and trying to find first set bit: 


while (words) { 
tmp = addr[--words]; 
if (tmp) { 
found: 
return words * BITS _PER_LONG + _ fls(tmp); 


Here we put the last word to the tmp variable and check that tmp contains at least one set 
bit. If a set bit found, we return the number of this bit. If no one words do not contains set bit 


we just return given size: 


return size; 


After this nr_cpu_ids will contain the correct amount of the available CPUs. 


That's all. 


Conclusion 


It is the end of the seventh part about the linux kernel initialization process. In this part, 

finally we have finished with the setup_arch function and returned to the start_kernel 

function. In the next part we will continue to learn generic kernel code from the 
start_kernel and will continue our way to the first init process. 


If you have any questions or suggestions write me a comment or ping me at twitter. 


Please note that English is not my first language, And | am really sorry for any 
inconvenience. If you find any mistakes please send me PR to linux-insides. 
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e Previous part 


Kernel initialization. Part 8. 


Scheduler initialization 


This is the eighth part of the Linux kernel initialization process and we stopped on the 

setup_nr_cpu_ids function in the previous part. The main point of the current part is 
scheduler initialization. But before we will start to learn initialization process of the scheduler, 
we need to do some stuff. The next step in the init/main.c is the setup_per_cpu_areas 
function. This function setups areas for the percpu variables, more about it you can read in 
the special part about the Per-CPU variables. After percpu areas is up and running, the 
next step is the smp_prepare_boot_cpu function. This function does some preparations for 
the SMP: 


static inline void smp_prepare_boot_cpu(void) 


{ 


smp_ops.smp_prepare_boot_cpu(); 


} 


where the smp_prepare_boot_cpu expands to the call of the native_smp_prepare_boot_cpu 
function (more about smp_ops will be in the special parts about swp ): 


void __init native_smp_prepare_boot_cpu(void) 
{ 
int me = smp_processor_id(); 
switch_to_new_gdt(me); 
cpumask_set_cpu(me, cpu_callout_mask); 
per_cpu(cpu_state, me) = CPU_ONLINE; 


The native_smp_prepare_boot_cpu function gets the id of the current CPU (which is 
Bootstrap processor and its id is zero) with the smp_processor_id function. | will not 
explain how the smp_processor_id works, because we already saw it in the Kernel entry 
point part. As we got processor id number we reload Global Descriptor Table for the given 
CPU with the switch_to_new_gdt function: 


void switch_to_new_gdt(int cpu) 


{ 
struct desc_ptr gdt_descr; 
gdt_descr.address = (long)get_cpu_gdt_table(cpu); 
gdt_descr.size = GDT_SIZE - 1; 
load_gdt(&gdt_descr); 
load_percpu_segment (cpu); 

} 


The gdt_descr variable represents pointer to the cpt descriptor here (we already saw 
desc_ptr in the Early interrupt and exception handling). We get the address and the size of 
the cpt descriptor where GDT_SIZE iS 256 Or: 


#define GDT_SIZE (GDT_ENTRIES * 8) 


and the address of the descriptor we will get with the get_cpu_gdt_table : 


static inline struct desc_struct *get_cpu_gdt_table(unsigned int cpu) 


{ 
return per_cpu(gdt_page, cpu).gdt; 


The get_cpu_gdt_table USes per_cpu macro for getting gdt_page percpu variable for the 
given CPU number (bootstrap processor with id -0 in our case). You may ask the 
following question: so, if we can access gdt_page percpu variable, where it was defined? 
Actually we already saw it in this book. If you have read the first part of this chapter, you can 
remember that we saw definition of the gdt_page in the arch/x86/kernel/head_64.S: 


early_gdt_descr: 

.word GDT_ENTRIES*8-1 
early_gdt_descr_base: 

. quad INIT_PER_CPU_VAR(gdt_page) 


and if we will look on the linker file we can see that it locates after the _ per_cpu load 
symbol: 


#define INIT_PER_CPU(x) init_per_cpu__##x = x + __per_cpu_load 
INIT_PER_CPU(gdt_page); 


and filled gdt_page in the arch/x86/kernel/cpu/common.c: 


DEFINE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page) = { .gdt = { 
#ifdef CONFIG_X86_64 











[GDT_ENTRY_KERNEL32_CS] = GDT_ENTRY_INIT(Oxc09b, 0, Oxfffff), 
[GDT_ENTRY_KERNEL_CS] = GDT_ENTRY_INIT(Oxa09b, 0, Oxfffff), 
[GDT_ENTRY_KERNEL_DS] = GDT_ENTRY_INIT(0xc093, 0, Oxfffff), 
[GDT_ENTRY_DEFAULT_USER32_CS] = GDT_ENTRY_INIT(OxcOfb, 0, Oxfffff), 
[GDT_ENTRY_DEFAULT_USER_DS] = GDT_ENTRY_INIT(OxcOf3, 0, Oxfffff), 
[GDT_ENTRY_DEFAULT_USER_CS] = GDT_ENTRY_INIT(Oxa0fb, 0, Oxfffff), 


more about percpu variables you can read in the Per-CPU variables part. As we got 
address and size of the cept descriptor we reload cpt with the load_gdt which just 
execute lgdt instruct and load percpu_segment with the following function: 


void load_percpu_segment(int cpu) { 
loadsegment(gs, 0); 
wrmsrl(MSR_GS_BASE, (unsigned long)per_cpu(irq_stack_union.gs_base, cpu)); 
load_stack_canary_segment(); 





The base address of the percpu area must contain gs register (or fs register for x86 ), 


SO we are using loadsegment macro and pass gs . In the next step we writes the base 


address if the IRQ stack and setup stack canary (this is only for xs6_32 ). After we load new 


GDT , we fill cpu_callout_mask bitmap with the current cpu and set cpu state as online with 


the setting cpu_state percpu variable for the current processor - CPU_ONLINE : 


cpumask_set_cpu(me, cpu_callout_mask); 
per_cpu(cpu_state, me) = CPU_ONLINE; 


So, what is cpu_callout_mask bitmap... As we initialized bootstrap processor (processor 
which is booted the first on x86 ) the other processors in a multiprocessor system are 
Known as secondary processors . Linux kernel uses following two bitmasks: 


@ cpu_callout_mask 


@ cpu_callin_mask 


After bootstrap processor initialized, it updates the cpu_callout_mask to indicate which 


secondary processor can be initialized next. All other or secondary processors can do some 


initialization stuff before and check the cpu_callout_mask on the boostrap processor bit. 
Only after the bootstrap processor filled the cpu_callout_mask with this secondary 


processor, it will continue the rest of its initialization. After that the certain processor finish its 


initialization process, the processor sets bit in the cpu_callin_mask . Once the bootstrap 


processor finds the bit in the cpu_callin_mask for the current secondary processor, this 
processor repeats the same procedure for initialization of one of the remaining secondary 
processors. In a short words it works as i described, but we will see more details in the 
chapter about smp . 


That's all. We did all smp boot preparation. 


Build zonelists 


In the next step we can see the call of the build_all_zonelists function. This function sets 
up the order of zones that allocations are preferred from. What are zones and what's order 
we will understand soon. For the start let's see how linux kernel considers physical memory. 
Physical memory is split into banks which are called - nodes . If you has no hardware 
support for numa , you will see only one node: 


$ cat /sys/devices/system/node/nodeO/numastat 
numa_hit 72452442 

numa_miss 0 

numa_foreign 0 

interleave_hit 12925 

local_node 72452442 

other_node 0 


Every node is presented by the struct pglist_data in the linux kernel. Each node is 
divided into a number of special blocks which are called - zones . Every zone is presented 
by the zone struct in the linux kernel and has one of the type: 


e ZONE_DMA - 0-16M; 

e ZONE_DMA32 - used for 32 bit devices that can only do DMA areas below 4G; 
e ZONE_NORMAL -all RAM from the 4GB on the x86 64 ; 

e ZONE_HIGHMEM - absent onthe x86 64 ; 

e ZONE_MOVABLE - zone which contains movable pages. 


which are presented by the zone_type enum. We can get information about zones with the: 


$ cat /proc/zoneinfo 


Node ©, zone DMA 
pages free 3975 
min 3 
low 3 


Node ©, zone DMA32 


pages free 694163 
min 875 
low 1093 


Node ©, zone Normal 


pages free 2529995 
min 3146 
low 3932 


As | wrote above all nodes are described with the pglist_data or pg_data_t structure in 
memory. This structure is defined in the include/linux/mmzone.h. The build_all_zonelists 
function from the mm/page_alloc.c constructs an ordered zonelist (of different zones 
DMA , DMA32 , NORMAL , HIGH MEMORY , MOVABLE ) which specifies the zones/nodes to visit 
when a selected zone or node cannot satisfy the allocation request. That's all. More about 
NuMA and multiprocessor systems will be in the special part. 


The rest of the stuff before scheduler 
initialization 


Before we will start to dive into linux kernel scheduler initialization process we must do a 
couple of things. The first thing is the page_alloc_init function from the mm/page_alloc.c. 
This function looks pretty easy: 


void __init page_alloc_init(void) 
{ 
hotcpu_notifier(page_alloc_cpu_notify, 0); 


and initializes handler for the cpu hotplug. Of course the hotcpu_notifier depends on the 
CONFIG_HOTPLUG_cPU configuration option and if this option is set, it just calls cpu_notifier 
macro which expands to the call of the register_cpu_notifier which adds hotplug cpu 
handler ( page_alloc_cpu_notify in our case). 


After this we can see the kernel command line in the initialization output: 


Linux version 4.1.0-rc2+ (alex@localhost) (gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13) ) #493 SMP Thu 





Command line: root=/dev/sdb earlyprintk=ttyS0,115200 loglevel=7 debug rdinit=/sbin/init root=/dev/ram 


And a couple of functions such aS parse early param and parse_args which handles linux 
kernel command line. You may remember that we already saw the call of the 

parse_early param function in the sixth part of the kernel initialization chapter, so why we 
call it again? Answer is simple: we call this function in the architecture-specific code 
( x86_64 in our case), but not all architecture calls this function. And we need to call the 
second function parse_args to parse and handle non-early command line arguments. 


In the next step we can see the call of the jump_label_init from the kernel/jump_label.c. 
and initializes jump label. 


After this we can see the call of the setup_log_buf function which setups the printk log 
buffer. We already saw this function in the seventh part of the linux kernel initialization 
process chapter. 


PID hash initialization 


The next is pidhash_init function. As you know each process has assigned a unique 
number which called - process identification number or PID . Each process generated 
with fork or clone is automatically assigned a new unique pip value by the kernel. The 
management of pips centered around the two special data structures: struct pid and 

struct upid . First structure represents information about a pip in the kernel. The second 
structure represents the information that is visible in a specific namespace. All pip 
instances stored in the special hash table: 


static struct hlist_head *pid_hash; 


This hash table is used to find the pid instance that belongs to a numeric pip value. So, 
pidhash_init initializes this hash table. In the start of the pidhash_init function we can 
see the call of the alloc_large_system_hash : 





pid_hash = alloc_large_system_hash("PID", sizeof(*pid_hash), ©, 18, 
HASH_EARLY | HASH_SMALL, 
&pidhash_shift, NULL, 
0, 4096); 





The number of elements of the pid_hash depends on the ram configuration, but it can be 
between 2^4 and 2412 . The pidhash_init Computes the size and allocates the required 
storage (which is hlist in our case - the same as doubly linked list, but contains one 


pointer instead on the struct hlist_head]. The alloc_large_system_hash function allocates a 





large system hash table with memblock_virt_alloc_nopanic if we pass HASH_EARLY flag (as it 
in our case) or with _ vmalloc if we did no pass this flag. 


The result we can see in the dmesg output: 


$ dmesg | grep hash 
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) 


That's all. The rest of the stuff before scheduler initialization is the following functions: 
vfs_caches_init_early does early initialization of the virtual file system (more about it will be 
in the chapter which will describe virtual file system), sort_main_extable sorts the kernel's 
built-in exception table entries which are between _ start___ex_table and 
__stop___ex_table , and trap_init initializes trap handlers (more about last two function 
we will know in the separate chapter about interrupts). 


The last step before the scheduler initialization is initialization of the memory manager with 
the mm_init function from the init/main.c. AS we can see, the mm_init function initializes 
different parts of the linux kernel memory manager: 


page_ext_init_flatmem(); 
mem_init(); 
kmem_cache_init(); 
percpu_init_late(); 
pgtable_init(); 
vmalloc_init(); 


The first is page_ext_init_flatmem which depends on the coNFIG_SPARSEMEM kernel 

configuration option and initializes extended data per page handling. The mem_init 

releases all bootmem , the kmem_cache_init initializes kernel cache, the percpu_init_late - 

replaces percpu chunks with those allocated by slub, the pgtable_init - initializes the 
page->ptl kernel cache, the vmalloc_init -initializes vmalloc . Please, NOTE that we will 

not dive into details about all of these functions and concepts, but we will see all of they it in 

the Linux kernel memory manager chapter. 


That's all. Now we can look on the scheduler . 


Scheduler initialization 


And now we come to the main purpose of this part - initialization of the task scheduler. | want 
to say again as | already did it many times, you will not see the full explanation of the 
scheduler here, there will be special chapter about this. Ok, next point is the sched_init 
function from the kernel/sched/core.c and as we can understand from the function's name, it 
initializes scheduler. Let's start to dive into this function and try to understand how the 
scheduler is initialized. At the start of the sched_init function we can see the following 
code: 


#ifdef CONFIG_FAIR_GROUP_SCHED 


alloc_size += 2 * nr_cpu_ids * sizeof(void **); 
#endif 
#ifdef CONFIG_RT_GROUP_SCHED 

alloc_size += 2 * nr_cpu_ids * Pon (Void) 2%) 
#endif 


First of all we can see two configuration options here: 


@ CONFIG_FAIR_GROUP_SCHED 


® CONFIG_RT_GROUP_SCHED 


Both of this options provide two different planning models. As we can read from the 
documentation, the current scheduler - crs Or Completely Fair Scheduler use a simple 
concept. It models process scheduling as if the system has an ideal multitasking processor 
where each process would receive 1/n processor time, where n is the number of the 
runnable processes. The scheduler uses the special set of rules. These rules determine 
when and how to select a new process to run and they are called scheduling policy . The 
Completely Fair Scheduler supports following normal or non-real-time scheduling 
policies: SCHED_NORMAL , SCHED BATCH and SCHED_IDLE . The SCHED_NORMAL is used for the 
most normal applications, the amount of cpu each process consumes is mostly determined 
by the nice value, the scHEp_BatcH used for the 100% non-interactive tasks and the 

SCHED_IDLE runs tasks only when the processor has no task to run besides this task. The 

real-time policies are also supported for the time-critical applications: scHED_FIFo and 

SCHED_RR . If you've read something about the Linux kernel scheduler, you can know that it 
is modular. It means that it supports different algorithms to schedule different types of 
processes. Usually this modularity is called scheduler classes . These modules encapsulate 
scheduling policy details and are handled by the scheduler core without knowing too much 
about them. 


Now let's back to the our code and look on the two configuration options 
CONFIG_FAIR_GROUP_SCHED and CONFIG_RT_GROUP_SCHED . The scheduler operates on an 
individual task. These options allows to schedule group tasks (more about it you can read in 


the CFS group scheduling). We can see that we assign the alloc_size variables which 
represent size based on amount of the processors to allocate for the sched_entity and 
cfs_rq tothe 2 * nr_cpu_ids * sizeof(void **) expression with kzalloc : 


ptr = (unsigned long)kzalloc(alloc_size, GFP_NOWAIT); 


#ifdef CONFIG_FAIR_GROUP_SCHED 
root_task_group.se = (struct sched_entity **)ptr; 
ptr += nr cpu ids * sizeof(void **); 


root_task_group.cfs_rq = (struct cfs_rq **)ptr; 
mvordi a); 





ptr += nr_cpu_ids * sizeo 
#endif 


The sched_entity is a structure which is defined in the include/linux/sched.h and used by 
the scheduler to keep track of process accounting. The cfs_rq presents run queue. So, 
you can see that we allocated space with size alloc_size for the run queue and scheduler 
entity of the root_task_group . The root_task_group is an instance of the task_group 
structure from the kerne!l/sched/sched.h which contains task group related information: 


struct task_group { 


struct sched_entity **se; 
struct cfs_rq **cfs_rq; 


The root task group is the task group which belongs to every task in system. As we allocated 
space for the root task group scheduler entity and runqueue, we go over all possible CPUs 

( cpu_possible_mask bitmap) and allocate zeroed memory from a particular memory node 
with the kzalloc_node function for the load_balance_mask percpu variable: 


DECLARE_PER_CPU(cpumask_var_t, load_balance_mask); 


Here cpumask_var_t is the cpumask_t with one difference: cpumask_var_t is allocated only 
nr_cpu_ids bits when the cpumask_t always has nr_cpus bits (more about cpumask you 
can read in the CPU masks part). As you can see: 


#ifdef CONFIG_CPUMASK_OFFSTACK 
for_each_possible_cpu(i) { 
per_cpu(load_balance_mask, i) = (cpumask_var_t)kzalloc_node( 
cpumask_size(), GFP_KERNEL, cpu_to_node(i)); 


} 
#endif 


this code depends on the coNFIG_cPUMASK_0FFSTACK configuration option. This configuration 
options says to use dynamic allocation for cpumask , instead of putting it on the stack. All 
groups have to be able to rely on the amount of CPU time. With the call of the two following 
functions: 


init_rt_bandwidth(&def_rt_bandwidth, 

global_rt_period(), global_rt_runtime()); 
init_d1_bandwidth(&def_d1_bandwidth, 

global_rt_period(), global_rt_runtime()); 


we initialize bandwidth management for the scHED_DEADLINE real-time tasks. These 
functions initializes rt_bandwidth and dl bandwidth structures which store information 
about maximum deadline bandwidth of the system. For example, let's look on the 
implementation of the init_rt_bandwidth function: 


void init_rt_bandwidth(struct rt_bandwidth *rt_b, u64 period, u64 runtime) 


{ 
rt_b->rt_period = ns_to_ktime(period); 
rt_b->rt_runtime = runtime; 


raw_spin_lock_init(&rt_b->rt_runtime_lock); 
hrtimer_init(&rt_b->rt_period_timer, 


CLOCK_MONOTONIC, HRTIMER_MODE_REL); 
rt_b->rt_period_timer.function = sched_rt_period_timer; 








It takes three parameters: 


e address of the rt_bandwidth structure which contains information about the allocated 
and consumed quota within a period; 

e period - period over which real-time task bandwidth enforcement is measured in us ; 

e runtime - part of the period that we allow tasks to run in us . 


AS period and runtime we pass result of the global_rt_period and global_rt_runtime 
functions. Which are 1s second and and o0.95s_ by default. The rt_bandwidth structure is 
defined in the kernel/sched/sched.h and looks: 


struct rt_bandwidth { 


raw_spinlock_t rt_runtime_lock; 
ktime_t rt_period; 

u64 rt_runtime; 
struct hrtimer rt_period_timer; 


}; 


As you can see, it contains runtime and period and also two following fields: 


e rt_runtime_lock -Spinlock forthe rt_time protection; 
e rt_period_timer - high-resolution kernel timer for unthrottled of real-time tasks. 


So, in the init_rt_bandwidth we initialize rt_bandwidth period and runtime with the given 
parameters, initialize the spinlock and high-resolution time. In the next step, depends on 
enable of SMP, we make initialization of the root domain: 


#ifdef CONFIG_SMP 
init_defrootdomain(); 
#endif 


The real-time scheduler requires global resources to make scheduling decision. But 
unfortunately scalability bottlenecks appear as the number of CPUs increase. The concept 
of root domains was introduced for improving scalability. The linux kernel provides a special 
mechanism for assigning a set of CPUs and memory nodes to a set of tasks and it is called - 

cpuset . lfa cpuset contains non-overlapping with other cpuset CPUs, itis exclusive 
cpuset . Each exclusive cpuset defines an isolated domain or root domain of CPUs 
partitioned from other cpusets or CPUs. A root domain is presented by the struct 
root_domain from the kernel/sched/sched.h in the linux kernel and its main purpose is to 
narrow the scope of the global variables to per-domain variables and all real-time scheduling 
decisions are made only within the scope of a root domain. That's all about it, but we will see 
more details about it in the chapter about real-time scheduler. 


After root domain initialization, we make initialization of the bandwidth for the real-time 
tasks of the root task group as we did it above: 


#ifdef CONFIG_RT_GROUP_SCHED 
init_rt_bandwidth(&root_task_group.rt_bandwidth, 
global_rt_period(), global_rt_runtime()); 
#endif 


In the next step, depends on the coNFIG_cGRouP_ScHED kernel configuration option we 
initialize the siblings and children lists of the root task group. As we can read from the 
documentation, the CONFIG_CGROUP_SCHED İS: 


This option allows you to create arbitrary task groups using the "cgroup" pseudo 
filesystem and control the cpu bandwidth allocated to each such task group. 


As we finished with the lists initialization, we can see the call of the autogroup_init 
function: 


#ifdef CONFIG_CGROUP_SCHED 
list_add(&root_task_group.list, &task_groups); 
INIT_LIST_HEAD(&root_task_group.children) ; 
INIT_LIST_HEAD(&root_task_group.siblings) ; 
autogroup_init(&init_task); 

#endif 


which initializes automatic process group scheduling. 


After this we are going through the all possible cpu (you can remember that possible 
CPUs store in the cpu_possible_mask bitmap that can ever be available in the system) and 
initialize a runqueue for each possible cpu: 


for_each_possible_cpu(i) { 
struct rq *rq; 


Each processor has its own locking and individual runqueue. All runnable tasks are stored in 
an active array and indexed according to its priority. When a process consumes its time 
slice, it is moved to an expired array. All of these arras are stored in the special structure 
which names is runqueue . As there are no global lock and runqueue, we are going through 
the all possible CPUs and initialize runqueue for the every cpu. The runqueue is presented 
by the rq structure in the linux kernel which is defined in the kernel/sched/sched.h. 


rq = cpu_rq(i); 
raw_spin_lock_init(&rq->lock); 
rq->nr_running = 0; 


rq->calc_load_active 0; 

rq->calc_load_update = jiffies + LOAD_FREQ; 
init_cfs_rq(&rq->cfs); 

init_rt_rq(&rg->rt); 

init_dl_rq(&rq->d1); 

rq->rt.rt_runtime = def_rt_bandwidth.rt_runtime; 


Here we get the runqueue for the every CPU with the cpu_rq macro which returns 

runqueues percpu variable and start to initialize it with runqueue lock, number of running 
tasks, calc_load relative fields ( calc_load_active and calc_load_update ) which are used 
in the reckoning of a CPU load and initialization of the completely fair, real-time and deadline 
related fields in a runqueue. After this we initialize cpu_load array with zeros and set the 
last load update tick to the jiffies variable which determines the number of time ticks 
(cycles), since the system boot: 


for (j = 0; j < CPU_LOAD_IDX_MAX; j++) 
rq->cpu_load[j] = 0; 


rq->last_load_update_tick = jiffies; 


where cpu_load keeps history of runqueue loads in the past, for now CPU_LOAD_IDX_MAX İS 

5. In the next step we fill runqueue fields which are related to the SMP, but we will not cover 

them in this part. And in the end of the loop we initialize high-resolution timer for the give 
runqueue and set the iowait (more about it in the separate part about scheduler) number: 


init_rq_hrtick(rq); 
atomic_set(&rq->nr_iowait, 0); 


Now we come out from the for_each_possible cpu loop and the next we need to set load 
weight for the init task with the set_load_weight function. Weight of process is calculated 
through its dynamic priority which is static priority + scheduling class of the process. After 
this we increase memory usage counter of the memory descriptor of the init process and 
set scheduler class for the current process: 


atomic_inc(&init_mm.mm_count); 
current->sched_class = &fair_sched_class; 


And make current process (it will be the first init process) idle and update the value of 
the calc_load_update with the 5 seconds interval: 


init_idle(current, smp_processor_id()); 
calc_load_update = jiffies + LOAD_FREQ; 


So, the init process will be run, when there will be no other candidates (as it is the first 
process in the system). In the end we just set scheduler_running variable: 


scheduler_running = 1; 


That's all. Linux kernel scheduler is initialized. Of course, we have skipped many different 
details and explanations here, because we need to know and understand how different 
concepts (like process and process groups, runqueue, rcu, etc.) works in the linux kernel , 
but we took a short look on the scheduler initialization process. We will look all other details 
in the separate part which will be fully dedicated to the scheduler. 


Conclusion 


It is the end of the eighth part about the linux kernel initialization process. In this part, we 
looked on the initialization process of the scheduler and we will continue in the next part to 
dive in the linux kernel initialization process and will see initialization of the RCU and many 
other initialization stuff in the next part. 


If you have any questions or suggestions write me a comment or ping me at twitter. 


Please note that English is not my first language, And | am really sorry for any 
inconvenience. If you find any mistakes please send me PR to linux-insides. 
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Kernel initialization. Part 9. 


RCU initialization 


This is ninth part of the Linux Kernel initialization process and in the previous part we 
stopped at the scheduler initialization. In this part we will continue to dive to the linux kernel 
initialization process and the main purpose of this part will be to learn about initialization of 
the RCU. We can see that the next step in the init/main.c after the sched_init is the call of 
the preempt_disable . There are two macros: 


e preempt_disable 


e preempt_enable 


for preemption disabling and enabling. First of all let's try to understand what is preempt in 
the context of an operating system kernel. In simple words, preemption is ability of the 
operating system kernel to preempt current task to run task with higher priority. Here we 
need to disable preemption because we will have only one init process for the early boot 
time and we don't need to stop it before we call cpu_idle function. The preempt_disable 
macro is defined in the include/linux/preempt.h and depends on the coNFIG PREEMPT_COUNT 
kernel configuration option. This macro is implemented as: 


#define preempt_disable() \ 

do { \ 
preempt_count_inc(); \ 
barrier(); \ 

} while (0) 


and if cCoNFIG_PREEMPT_COUNT is not set just: 


#define preempt_disable() barrier() 


Let's look on it. First of all we can see one difference between these macro implementations. 
The preempt_disable with coNFIG_PREEMPT_couNT set contains the call of the 

preempt_count_inc . There is special percpu variable which stores the number of held locks 
and preempt_disable calls: 


DECLARE_PER_CPU(int, __preempt_count); 


In the first implementation of the preempt_disable we increment this __preempt_count . 

There is API for returning value of the _ preempt count , itis the preempt_count function. As 

we called preempt_disable , first of all we increment preemption counter with the 
preempt_count_inc macro which expands to the: 


#define preempt_count_inc() preempt_count_add(1) 
#define preempt_count_add(val) _ preempt_count_add(val) 


where preempt_count_add calls the raw_cpu_add_4 macro which adds 1 to the given 

percpu Variable ( __preempt_count ) in our case (more about precpu variables you can 
read in the part about Per-CPU variables). Ok, we increased __preempt_count and the next 
step we can see the call of the barrier macro inthe both macros. The barrier macro 
inserts an optimization barrier. In the processors with x86 64 architecture independent 
memory access operations can be performed in any order. That's why we need the 
opportunity to point compiler and processor on compliance of order. This mechanism is 
memory barrier. Let's consider a simple example: 


preempt_disable(); 
foo(); 
preempt_enable(); 


Compiler can rearrange it as: 


preempt_disable(); 
preempt_enable(); 
foo(); 


In this case non-preemptible function foo can be preempted. As we put barrier macro in 
the preempt_disable and preempt_enable macros, it prevents the compiler from swapping 
preempt_count_inc with other statements. More about barriers you can read here and here. 


In the next step we can see following statement: 


if (WARN(!irqs_disabled(), 
"Interrupts were enabled *very* early, fixing it\n")) 
local_irq_disable(); 


which check IRQs state, and disabling (with cli instruction for xs6_64 ) if they are 
enabled. 


That's all. Preemption is disabled and we can go ahead. 


Initialization of the integer ID management 


In the next step we can see the call of the idr_init_cache function which defined in the 
lib/idr.c. The iar library is used in a various places in the linux kernel to manage assigning 
integer 1Ds_ to objects and looking up objects by id. 


Let's look on the implementation of the idr_init_cache function: 


void _ init idr_init_cache(void) 


{ 
idr_layer_cache = kmem_cache_create("idr_layer_cache", 
sizeof(struct idr_layer), ©, SLAB_PANIC, NULL); 


Here we can see the call of the kmem_cache_create . We already called the kmem cache init 
in the init/main.c. This function create generalized caches again using the kmem cache alloc 
(more about caches we will see in the Linux kernel memory management chapter). In our 
Case, aS we are Using kmem_cache_t which will be used by the slab allocator and 
kmem_cache_create Creates it. AS you can see we pass five parameters to the 


kmem_cache_create 


e name of the cache; 
e size of the object to store in cache; 


offset of the first object in the page; 
e flags; 
e constructor for the objects. 


and it will create kmem_cache for the integer IDs. Integer tps is commonly used pattern to 
map set of integer IDs to the set of pointers. We can see usage of the integer IDs in the i2c 
drivers subsystem. For example drivers/i2c/i2c-core.c which represents the core of the i2c 
subsystem defines 1p forthe i2c adapter with the DEFINE_IDR macro: 


static DEFINE_IDR(i2c_adapter_idr); 


and then uses it for the declaration of the i2c adapter: 


static int __i2c_add_numbered_adapter(struct i2c_adapter *adap) 


{ 


int id; 


id = idr_alloc(&i2c_adapter_idr, adap, adap->nr, adap->nr + 1, GFP_KERNEL); 


and id2_adapter_idr presents dynamically calculated bus number. 


More about integer ID management you can read here. 


RCU initialization 


The next step is RCU initialization with the rcu_init function and it's implementation 
depends on two kernel configuration options: 


@ CONFIG_TINY_RCU 


® CONFIG_TREE_RCU 


In the first case rcu_init will be in the kernel/rcu/tiny.c and in the second case it will be 
defined in the kernel/rcu/tree.c. We will see the implementation of the tree rcu , but first of 
all about the rcu in general. 


RCU or read-copy update is a scalable high-performance synchronization mechanism 
implemented in the Linux kernel. On the early stage the linux kernel provided support and 
environment for the concurrently running applications, but all execution was serialized in the 
kernel using a single global lock. In our days linux kernel has no single global lock, but 
provides different mechanisms including !ock-free data structures, percpu data structures 
and other. One of these mechanisms is - the read-copy update . The rcu technique is 
designed for rarely-modified data structures. The idea of the rcu is simple. For example we 
have a rarely-modified data structure. If somebody wants to change this data structure, we 
make a copy of this data structure and make all changes in the copy. In the same time all 
other users of the data structure use old version of it. Next, we need to choose safe moment 
when original version of the data structure will have no users and update it with the modified 


copy. 
Of course this description of the rcu is very simplified. To understand some details about 


RCU , first of all we need to learn some terminology. Data readers in the rcu executed in 
the critical section. Every time when data reader get to the critical section, it calls the 


rcu_read_lock , and rcu_read_unlock on exit from the critical section. If the thread is not in 
the critical section, it will be in state which called - quiescent state . The moment when 
every thread is in the quiescent state called- grace period . If a thread wants to remove 
an element from the data structure, this occurs in two steps. First step is removal - 
atomically removes element from the data structure, but does not release the physical 
memory. After this thread-writer announces and waits until it is finished. From this moment, 
the removed element is available to the thread-readers. After the grace period finished, the 
second step of the element removal will be started, it just removes the element from the 
physical memory. 


There a couple of implementations of the rcu . Old rcu called classic, the new 
implementation called tree RCU. As you may already understand, the coNFIG TREE_RCU 
kernel configuration option enables tree rcu . Another is the tiny RCU which depends on 

CONFIG_TINY_RCU and coNFIG_SMP=n . We will see more details about the rcu in general in 
the separate chapter about synchronization primitives, but now let's look on the rcu_init 
implementation from the kernel/rcu/tree.c: 


void __init rcu_init(void) 
{ 


int cpu; 


rcu_bootup_announce(); 

rcu_init_geometry(); 

rcu_init_one(&rcu_bh_state, &rcu_bh_data); 
rcu_init_one(&rcu_sched_state, &rcu_sched_data); 
__rcu_init_preempt(); 

open_softirgq(RCU_SOFTIRQ, rcu_process_callbacks); 


cpu_notifier(rcu_cpu_notify, 9); 
pm_notifier(rcu_pm_notify, 0); 
for_each_online_cpu(cpu) 
rcu_cpu_notify(NULL, CPU_UP_PREPARE, (void *)(long)cpu); 


rcu_early_boot_tests(); 


In the beginning of the rcu_init function we define cpu variable and call 
rcu_bootup_announce . The rcu_bootup_announce function is pretty simple: 


static void _ init bootup_announce(void) 
{ 


pr_info("Hierarchical RCU implementation.\n"); 
rcu_bootup_announce_oddness(); 


It just prints information about the rcu with the pr_info function and 

rcu_bootup_announce_oddness Which uses pr_info too, for printing different information 
about the current rcu configuration which depends on different kernel configuration options 
like CONFIG_RCU_TRACE , CONFIG_PROVE_RCU , CONFIG_RCU_FANOUT_EXACT , etc. In the next step, 
we can see the call of the rcu_init_geometry function. This function is defined in the same 
source code file and computes the node tree geometry depends on the amount of CPUs. 
Actually rcu provides scalability with extremely low internal RCU lock contention. What if a 
data structure will be read from the different CPUs? rcu API provides the rcu_state 
structure which presents RCU global state including node hierarchy. Hierarchy is presented 
by the: 


struct rcu_node node[NUM_RCU_NODES]; 


array of structures. As we can read in the comment of above definition: 


The root (first level) of the hierarchy is in ->node[0] (referenced by ->level[0]), th 
e second 

level in ->node[1] through ->node[m] (->node[1] referenced by ->level[1]), and the thi 
rd level 

in ->node[m+1] and following (->node[m+1] referenced by ->level[2]). The number of le 
vels is 

determined by the number of CPUs and by CONFIG_RCU_FANOUT. 


Small systems will have a "hierarchy" consisting of a single rcu_node. 


The rcu_node structure is defined in the kernel/rcu/tree.h and contains information about 
current grace period, is grace period completed or not, CPUs or groups that need to switch 
in order for current grace period to proceed, etc. Every rcu_node contains a lock for a 
couple of CPUs. These rcu node structures are embedded into a linear array in the 

rcu_state structure and represented as a tree with the root as the first element and covers 
all CPUs. As you can see the number of the rcu nodes determined by the NUM_RCU_NODES 
which depends on number of available CPUs: 


#define NUM_RCU_NODES (RCU_SUM - NR_CPUS) 
#define RCU_SUM (NUM_RCU_LVL_@ + NUM_RCU_LVL_1 + NUM_RCU_LVL_2 + NUM_RCU_LVL_3 + NUM_R 
CU_LVL_4) 


where levels values depend on the coNFIG RCU_FANOUT_LEAF configuration option. For 
example for the simplest case, one rcu_node will cover two CPU on machine with the eight 
CPUs: 


+----------------------------------------------------------------- 十 
| rcu_state | 
| t= + | 
| | root | | 
| | rcu_node | | 
| hace eae see Seema es ee + | 
| | | | 
| = VV eee 十 下 十 | 
| | | | | | 
| | rcu_node | | rcu_node | | 
| | | | | | 
| eE a + Pee + | 
| | | | | | 
| | | | | | 
| es ee + ee SoA v--+ Pain eae a + VD eos + | 
| | | | al | | | | 
| | rcu_node | | rcu_node | | rcu_node | | rcu_node | | 
| | | | ll | | | | 
| Hoe ke Sei + eae ees ies + Ses eee | oo ee + | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
a 人 | [a E + 
| | | | 
+--------- V----------------- V------------- V--------------- V-------- oF 
| | | | | 
| CPU1 | CPU3 | CPU5 | CPU7 | 
| | | | | 
| CPU2 | CPU4 | CPU6 | CPU8 | 
| | | | | 
+------------------------------------------------------------------ 十 


So, in the rcu_init_geometry function we just need to calculate the total number of 
rcu_node structures. We start to do it with the calculation of the jiffies till to the first and 
next fqs whichis force-quiescent-state (read above about it): 


d = RCU_JIFFIES TILL_FORCE_QS + nr_cpu_ids / RCU_JIFFIES_FQS DIV; 
if (jiffies_till_first_fqs == ULONG_MAX) 

jiffies_till_first_fqs = d; 
if (jiffies_till_next_fqs == ULONG_MAX) 

jiffies_till_next_fqs = d; 


where: 


#define RCU_JIFFIES_TILL_FORCE_QS (1 + (HZ > 250) + (HZ > 500)) 
#define RCU_JIFFIES_FQS_DIV 256 


As we calculated these jiffies, we check that previous defined jiffies till first_fqs and 
jiffies_till_next_fqs variables are equal to the ULONG MAX (their default values) and 
set they equal to the calculated value. As we did not touch these variables before, they are 

equal to the ULONG_MAx : 


static ulong jiffies_till_first_fqs = ULONG_MAX; 
static ulong jiffies_till_next_fqs = ULONG MAX; 


In the next step of the rcu_init_geometry , we check that rcu_fanout_leaf didn't change (it 
has the same value aS CONFIG_RCU_FANOUT_LEAF in Compile-time) and equal to the value of 
the CONFIG_RCU_FANOUT_LEAF configuration option, we just return: 


if (rcu_fanout_leaf == CONFIG_RCU_FANOUT_LEAF && 
nr_cpu_ids == NR_CPUS) 
return; 


After this we need to compute the number of nodes that an rcu_node tree can handle with 
the given number of levels: 


1; 
rcu_capacity[1] = rcu_fanout_leaf; 
for (i = 2; i <= MAX_RCU_LVLS; i++) 
rcu_capacity[i] = rcu_capacity[i - 1] * CONFIG_RCU_FANOUT; 


rcu_capacity[0] 


And in the last step we calculate the number of rcu_nodes at each level of the tree in the 
loop. 


As we calculated geometry of the rcu_node tree, we need to go back to the rcu_init 
function and next step we need to initialize two rcu_state structures with the rcu_init_one 
function: 


rcu_init_one(&rcu_bh_state, &rcu_bh_data); 
rcu_init_one(&rcu_sched_state, &rcu_sched_data); 
The rcu_init_one function takes two arguments: 


e Global rcu state; 
e Per-CPU data for rcu. 


Both variables defined in the kernel/rcu/tree.h with its percpu data: 


extern struct rcu_state rcu_bh_state; 
DECLARE_PER_CPU(struct rcu_data, rcu_bh_data); 


About this states you can read here. As | wrote above we need to initialize rcu_state 
structures and rcu_init_one function will help us with it. After the rcu_state initialization, 
we can see the call of the _ _rcu_init_preempt which depends on the coNFIG PREEMPT_RCU 
kernel configuration option. It does the same as previous functions - initialization of the 

rcu_preempt_state structure with the rcu_init_one function which has rcu_state type. 
After this, in the rcu_init , we can see the call of the: 


open_softirgq(RCU_SOFTIRQ, rcu_process_callbacks); 


function. This function registers a handler of the pending interrupt . Pending interrupt or 
softirq supposes that part of actions can be delayed for later execution when the system 
is less loaded. Pending interrupts is represented by the following structure: 


struct softirq_action 


{ 


void (*action)(struct softirq_action *); 


}; 


which is defined in the include/linux/interrupt.h and contains only one field - handler of an 
interrupt. You can check about softirgs in the your system with the: 


$ cat /proc/softirgs 


CPUO CPU1 CPU2 CPU3 CPU4 CPUS 
CPU6 CPU7 
HI: 2 0 0 1 0 2 
0 0 
TIMER: 137779 108110 139573 107647 107408 114972 9 
9653 98665 
NET_TX: 1127 0 4 0 1 工 
0 0 
NET_RX: 334 221 132939 3076 451 361 
292 303 
BLOCK: 5253 5596 8 779 2016 37442 
28 2855 
BLOCK_IOPOLL: 0 0 0 0 0 0 
0 0 
TASKLET : 66 0 2916 113 0 24 2 
6708 0 
SCHED: 102350 75950 91705 75356 75323 82627 6 
9279 69914 
HRTIMER: 510 302 368 260 219 255 
248 246 
RCU: 81290 68062 82979 69015 68390 69385 6 
3304 63473 


The open_softirg function takes two parameters: 


e index of the interrupt; 
e interrupt handler. 


and adds interrupt handler to the array of the pending interrupts: 


void open_softirq(int nr, void (*action)(struct softirq_action *)) 


{ 


softirq_vec[nr].action = action; 


In our case the interrupt handler is - rcu_process_callbacks which is defined in the 
kernel/rcu/tree.c and does the rcu core processing for the current CPU. After we registered 
softirq interrupt for the rcu , we can see the following code: 


cpu_notifier(rcu_cpu_notify, 0); 
pm_notifier(rcu_pm_notify, 0); 
for_each_online_cpu(cpu) 
rcu_cpu_notify(NULL, CPU_UP_PREPARE, (void *)(long)cpu); 


Here we can see registration of the cpu notifier which needs in systems which supports 
CPU hotplug and we will not dive into details about this theme. The last function in the 


rcu_init is the rcu_early_boot_tests : 


void rcu_ear 00 ests(void) 
{ 
pr_info("Running RCU self tests\n"); 


if (rcu_self_test) 
early_boot_test_call_rcu(); 

if (rcu_self_test_bh) 
early_boot_test_call_rcu_bh(); 

if (rcu_self_test_sched) 


early_boot_test_call_rcu_sched(); 











which runs self tests for the rcu . 


That's all. We saw initialization process of the rcu subsystem. As | wrote above, more 
about the rcu will be in the separate chapter about synchronization primitives. 


Rest of the initialization process 


Ok, we already passed the main theme of this part which is rcu initialization, but it is not 

the end of the linux kernel initialization process. In the last paragraph of this theme we will 

see a couple of functions which work in the initialization time, but we will not dive into deep 
details around this function for different reasons. Some reasons not to dive into details are 
following: 


e They are not very important for the generic kernel initialization process and depend on 
the different kernel configuration; 

e They have the character of debugging and not important for now; 

e We will see many of this stuff in the separate parts/chapters. 


After we initialized rcu , the next step which you can see in the init/main.c is the - 
trace_init function. As you can understand from its name, this function initialize tracing 
subsystem. You can read more about linux kernel trace system - here. 


After the trace_init , we can see the call of the radix_tree_init . If you are familiar with 
the different data structures, you can understand from the name of this function that it 
initializes kernel implementation of the Radix tree. This function is defined in the lib/radix- 
tree.c and you can read more about it in the part about Radix tree. 


In the next step we can see the functions which are related to the interrupts handling 
subsystem, they are: 


e early_irgq_init 
© init_IRQ 


e softirq init 


We will see explanation about this functions and their implementation in the special part 
about interrupts and exceptions handling. After this many different functions (like 

init_timers , hrtimers_init , time_init , etc.) which are related to different timing and 
timers stuff. We will see more about these function in the chapter about timers. 


The next couple of functions are related with the perf events - perf_event-init (there will 
be separate chapter about perf), initialization of the profiling with the profile init . After 
this we enable irq with the call of the: 


local_irq_enable(); 


which expands to the sti instruction and making post initialization of the SLAB with the call 
of the kmem_cache_init_late function (As | wrote above we will know about the slas in the 
Linux memory management chapter). 


After the post initialization of the slas , next point is initialization of the console with the 
console_init function from the drivers/tty/tty_io.c. 


After the console initialization, we can see the lockdep_info function which prints 
information about the Lock dependency validator. After this, we can see the initialization of 
the dynamic allocation of the debug objects with the debug_objects_mem_init , kernel 
memory leak detector initialization with the kmemleak_init , percpu pageset setup with the 

setup_per_cpu_pageset , setup of the NUMA policy with the numa_policy_init , setting time 
for the scheduler with the sched_clock_init , pidmap initialization with the call of the 

pidmap_init function for the initial PID namespace, cache creation with the 

anon_vma_init for the private virtual memory areas and early initialization of the ACP! with 
the acpi_early_init . 


This is the end of the ninth part of the linux kernel! initialization process and here we saw 
initialization of the RCU. In the last paragraph of this part ( Rest of the initialization 
process ) we will go through many functions but did not dive into details about their 
implementations. Do not worry if you do not know anything about these stuff or you know 
and do not understand anything about this. As | already wrote many times, we will see 
details of implementations in other parts or other chapters. 


Conclusion 


It is the end of the ninth part about the linux kernel initialization process. In this part, we 
looked on the initialization process of the rcu subsystem. In the next part we will continue 
to dive into linux kernel initialization process and | hope that we will finish with the 

start_kernel function and will go tothe rest_init function from the same init/main.c 
source code file and will see the start of the first process. 


If you have any questions or suggestions write me a comment or ping me at twitter. 


Please note that English is not my first language, And | am really sorry for any 
inconvenience. If you find any mistakes please send me PR to linux-insides. 


Links 


e lock-free data structures 

e kmemleak 

e ACPI 

e IRQs 

e RCU 

e RCU documentation 

e integer ID management 

e Documentation/memory-barriers.txt 
e Runtime locking correctness validator 
e Per-CPU variables 

e Linux kernel memory management 
e slab 

e i2c 

e Previous part 


Kernel initialization. Part 10. 


End of the linux kernel initialization 
process 


This is tenth part of the chapter about linux kernel initialization process and in the previous 
part we saw the initialization of the RCU and stopped on the call of the acpi_early_init 
function. This part will be the last part of the Kernel initialization process chapter, so let's 
finish it. 

After the call of the acpi_early_init function from the init/main.c, we can see the following 
code: 


#ifdef CONFIG_X86_ESPFIX64 
init_espfix_bsp(); 
#endif 


Here we can see the call of the init_espfix_bsp function which depends on the 

CONFIG X86_ESPFIX64 kernel configuration option. As we can understand from the function 
name, it does something with the stack. This function is defined in the 
arch/x86/kernel/espfix_64.c and prevents leaking of 31:16 bits of the esp register during 
returning to 16-bit stack. First of all we install espfix page upper directory into the kernel 
page directory in the init_espfix_bs : 


pgd_p = &init_level4_pgt[pgd_index(ESPFIX_BASE_ADDR) ]; 
pgd_populate(&init_mm, pgd_p, (pud_t *)espfix_pud_page); 


Where ESPFIX_BASE_ADDR iS: 


#define PGDIR_SHIFT 39 
#define ESPFIX_PGD_ENTRY _AC(-2, UL) 
#define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << PGDIR_SHIFT) 


Also we can find it in the Documentation/x86/x86_64/mm: 


. unused hole ... 
ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks 
. unused hole ... 


After we've filled page global directory with the espfix pud, the next step is call of the 
init_espfix_random and init_espfix_ap functions. The first function returns random 

locations for the espfix page and the second enables the espfix for the current CPU. 

After the init_espfix_bsp finished the work, we can see the call of the 
thread_info_cache_init function which defined in the kernel/fork.c and allocates cache for 


the thread_info if THREAD SIZE is less than PAGE_SIZE : 


# if THREAD SIZE >= PAGE_SIZE 


void thread_info_cache_init(void) 


thread_info_cache = kmem_cache_create("thread_info", THREAD _SIZE, 
THREAD_SIZE, ©, NULL); 
BUG_ON(thread_info_cache == NULL); 


#endif 


As we already know the PAGE_SIZE iS (_AC(1,UL) << PAGE_SHIFT) or 4096 bytes and 
THREAD_SIZE İS (PAGE_SIZE << THREAD _SIZE_ORDER) Or 16384 bytes forthe x86 64 . The 
next function after the thread_info_cache_init is the cred_init from the kernel/cred.c. This 
function just allocates cache for the credentials (like uid , gid , etc.): 


void __init cred_init(void) 
{ 


cred_jar = kmem_cache_create("cred_jar", sizeof(struct cred), 
O, SLAB _HWCACHE_ALIGN|SLAB_ PANIC, NULL); 


more about credentials you can read in the Documentation/security/credentials.txt. Next step 
is the fork_init function from the kernel/fork.c. The fork_init function allocates cache for 
the task_struct . Let's look on the implementation of the fork_init . First of all we can see 
definitions of the ARCH_MIN_TASKALIGN macro and creation of a slab where task_structs will 
be allocated: 


#ifndef CONFIG_ARCH_TASK_STRUCT_ALLOCATOR 
#ifndef ARCH_MIN_TASKALIGN 

#define ARCH_MIN_TASKALIGN L1_CACHE_BYTES 
#endif 





task_struct_cachep = 
kmem_cache_create("task_struct", sizeof(struct task_struct), 
ARCH_MIN_TASKALIGN, SLAB PANIC | SLAB_NOTRACK, NULL); 
#endif 


As we can see this code depends on the coNFIG_ARCH_TASK_STRUCT_ACLLOCATOR kernel 





configuration option. This configuration option shows the presence of the alloc_task_struct 
for the given architecture. AS x86 64 has no alloc_task_struct function, this code will not 
work and even will not be compiled on the xs6_64 . 


Allocating cache for init task 


After this we can see the call of the arch_task_cache_init function in the fork_init : 


void arch_task_cache_init (void) 


task_xstate_cachep = 
kmem_cache_create("task_xstate", xstate_size, 
__alignof__(union thread_xstate), 
SLAB_PANIC | SLAB _NOTRACK, NULL); 
setup_xstate_comp(); 


The arch_task_cache_init does initialization of the architecture-specific caches. In our case 

itis x86 64 , SO as we can see, the arch_task_cache_init allocates cache for the 
task_xstate which represents FPU state and sets up offsets and sizes of all extended 

states in xsave area with the call of the setup_xstate_comp function. After the 
arch_task_cache_init we calculate default maximum number of threads with the: 


set_max_threads(MAX_THREADS) ; 


where default maximum number of threads is: 


#define FUTEX_TID_MASK Ox3fffffff 
#define MAX_THREADS FUTEX_TID_MASK 


In the end of the fork_init function we initialize signal handler: 


init_task.signal->rlim[RLIMIT_NPROC].rlim_cur 

init_task.signal->rlim[RLIMIT_NPROC].rlim_max 

init_task.signal->rlim[RLIMIT_SIGPENDING] = 
init_task.signal->rlim[RLIMIT_NPROC]; 


max_threads/2; 
max_threads/2; 


As we know the init_task is an instance of the task_struct structure, so it contains 


signal field which represents signal handler. It has following type struct signal_struct . 


On the first two lines we can see setting of the current and maximum limit of the resource 


limits . Every process has an associated set of resource limits. These limits specify amount 


of resources which current process can use. Here rlim is resource control limit and 


presented by the: 


struct rlimit { 


kernel_ulong_t rlim_cur; 





kernel_ulong_t rlim_max; 





}; 


structure from the include/uapi/linux/resource.h. In our case the resource is the 


RLIMIT_NPROcC which is the maximum number of processes that user can own and 


RLIMIT_SIGPENDING - the maximum number of pending signals. We can see it in the: 


cat /proc/self/limits 


Limit Soft Limit 
Max processes 63815 
Max pending signals 63815 


Hard Limit Units 
63815 processes 
63815 signals 


Initialization of the caches 


The next function after the fork_init is the proc_caches_init from the kernel/fork.c. This 


function allocates caches for the memory descriptors (or mm_struct structure). At the 


beginning of the proc_caches_init we can see allocation of the different SLAB caches with 


the call of the kmem_cache_create 


e sighand_cachep - manage information about installed signal handlers; 


e signal_cachep - Manage information about process signal descriptor; 


e files_cachep - manage information about opened files; 


e fs_cachep - manage filesystem information. 


After this we allocate stas cache for the mm_struct structures: 


mm_cachep = kmem_cache_create("mm_struct", 
sizeof(struct mm_struct), ARCH _MIN_MMSTRUCT_ALIGN, 
SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK, NULL); 


After this we allocate slas cache for the important vm_area_struct which used by the 
kernel to manage virtual memory space: 


vm_area_cachep = KMEM_CACHE(vm_area_struct, SLAB _PANIC); 


Note, that we use KMEM_CACHE macro here instead of the kmem_cache_create . This macro is 
defined in the include/linux/slab.h and just expands to the kmem_cache_create call: 


#define KMEM_CACHE(__struct, _ flags) kmem_cache_create(#__struct,\ 
sizeof(struct _ struct), _alignof_ (struct __struct),\ 
(flags), NULL) 


The Kmem_cacHE has one difference from kmem_cache_create . Take alook on _ alignof 
operator. The kmem_cacHE macro aligns slas to the size of the given structure, but 
kmem_cache_create uses given value to align space. After this we can see the call of the 
mmap_init and nsproxy_cache_init functions. The first function initializes virtual memory 
area _ SLAB and the second function initializes slas for namespaces. 


The next function after the proc_caches_init İS buffer_init . This function is defined in the 
fs/buffer.c source code file and allocate cache for the buffer_head . The buffer_head isa 
special structure which defined in the include/linux/buffer_head.h and used for managing 
buffers. In the start of the buffer_init function we allocate cache for the struct 
buffer_head structures with the call of the kmem_cache_create function as we did in the 
previous functions. And calculate the maximum size of the buffers in memory with: 


nrpages = (nr_free_buffer_pages() * 10) / 100; 
max_buffer_heads = nrpages * (PAGE_SIZE / sizeof(struct buffer_head) ); 


which will be equal to the 10% of the zoNE_NORMAL (all RAM from the 4GB on the xs6_64 ). 
The next function after the buffer_init iS- vfs_caches_init . This function allocates sLaB 
caches and hashtable for different VFS caches. We already saw the vfs_caches_init_early 
function in the eighth part of the linux kernel initialization process which initialized caches for 
dcache (or directory-cache) and inode cache. The vfs_caches_init function makes post- 
early initialization of the dcache and inode caches, private data cache, hash tables for the 


mount points, etc. More details about VFS will be described in the separate part. After this 
we can see signals_init function. This function is defined in the kernel/signal.c and 
allocates a cache for the sigqueue structures which represents queue of the real time 
signals. The next function is page_writeback_init . This function initializes the ratio for the 
dirty pages. Every low-level page entry contains the dirty bit which indicates whether a 
page has been written to after been loaded into memory. 


Creation of the root for the procfs 


After all of this preparations we need to create the root for the proc filesystem. We will do it 
with the call of the proc_root_init function from the fs/proc/root.c. At the start of the 

proc_root_init function we allocate the cache for the inodes and register a new filesystem 
in the system with the: 


err = register_filesystem(&proc_fs_type); 
if (err) 
return; 


As | wrote above we will not dive into details about VFS and different filesystems in this 
chapter, but will see it in the chapter about the ves . After we've registered a new filesystem 
in our system, we call the proc_self_init function from the fs/proc/self.c and this function 
allocates inode number forthe self ( /proc/self directory refers to the process 
accessing the /proc filesystem). The next step after the proc_self_init is 
proc_setup_thread_self which setups the /proc/thread-self directory which contains 





information about current thread. After this we create /proc/self/mounts symlink which will 
contains mount points with the call of the 


proc_symlink("mounts", NULL, "self/mounts"); 


and a couple of directories depends on the different configuration options: 


#ifdef CONFIG_SYSVIPC 
proc_mkdir("sysvipc", NULL); 
#endif 
proc_mkdir("fs", NULL); 
proc_mkdir("driver", NULL); 
proc_mkdir("fs/nfsd", NULL); 
#if defined(CONFIG_SUN_OPENPROMFS) || defined(CONFIG_SUN_OPENPROMFS_MODULE ) 
proc_mkdir("openprom", NULL); 
#endif 
proc_mkdir("bus", NULL); 


if (!proc_mkdir("tty", NULL)) 
return; 
proc_mkdir("tty/ldisc", NULL); 


In the end of the proc root init we call the proc_sys_init function which creates 
/proc/sys directory and initializes the Syscil. 


It is the end of start_kernel function. | did not describe all functions which are called in the 
start_kernel . | skipped them, because they are not important for the generic kernel 
initialization stuff and depend on only different kernel configurations. They are 
taskstats_init_early which exports per-task statistic to the user-space, delayacct_init - 
initializes per-task delay accounting, key_init and security_init initialize different 
security stuff, check_bugs - fix some architecture-dependent bugs, ftrace_init function 
executes initialization of the ftrace, cgroup_init makes initialization of the rest of the cgroup 
subsystem,etc. Many of these parts and subsystems will be described in the other chapters. 


That's all. Finally we have passed through the long-long  start_kernel function. But it is not 
the end of the linux kernel initialization process. We haven't run the first process yet. In the 
end of the start_kernel we can see the last call of the - rest_init function. Let's go 
ahead. 


First steps after the start_kernel 


The rest_init function is defined in the same source code file as start_kernel function, 
and this file is init/main.c. In the beginning of the rest_init we can see call of the two 
following functions: 


rcu_scheduler_starting(); 
smpboot_thread_init(); 


The first rcu_scheduler_starting makes RCU scheduler active and the second 
smpboot_thread_init registers the smpboot_thread_notifier CPU notifier (more about it you 
can read in the CPU hotplug documentation. After this we can see the following calls: 


kernel_thread(kernel_init, NULL, CLONE_FS); 
pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE _FILES); 


Here the kernel_thread function (defined in the kernel/fork.c) creates new kernel thread.As 
we can see the kernel_thread function takes three arguments: 


e Function which will be executed in a new thread; 
e Parameter for the kernel_init function; 
e Flags. 


We will not dive into details about kernel_thread implementation (we will see it in the 
chapter which describe scheduler, just need to say that kernel_thread invokes clone). Now 
we only need to know that we create new kernel thread with kernel_thread function, parent 
and child of the thread will use shared information about filesystem and it will start to 
execute kernel_init function. A kernel thread differs from a user thread that it runs in 
kernel mode. So with these two kernel_thread calls we create two new kernel threads with 
the pip = 1 for init process and pip = 2 for kthreadd . We already know what is init 
process. Let's look on the kthreadd . It is a special kernel thread which manages and helps 
different parts of the kernel to create another kernel thread. We can see it in the output of 
the ps util: 


$ ps -ef | grep kthread 
root 2 © © Janii ? 00:00:00 [kthreadd] 


Let's postpone kernel_init and kthreadd for now and go ahead inthe rest_init . In the 
next step after we have created two new kernel threads we can see the following code: 


rcu_read_lock(); 
kthreadd_task = find_task_by_pid_ns(pid, &init_pid_ns); 
rcu_read_unlock(); 


The first rcu_read_lock function marks the beginning of an RCU read-side critical section 
and the rcu_read_unlock marks the end of an RCU read-side critical section. We call these 
functions because we need to protect the find_task_by_pid_ns . The find_task_by_pid_ns 


returns pointer to the task_struct by the given pid. So, here we are getting the pointer to 
the task_struct for PID = 2 (we gotit after kthreadd creation with the kernel_thread ). In 
the next step we call complete function 


complete(&kthreadd_done); 


and pass address of the kthreadd_done . The kthreadd_done defined as 


static __initdata DECLARE_COMPLETION(kthreadd_done); 


where DECLARE_COMPLETION macro defined as: 


#define DECLARE_COMPLETION(work) \ 
struct completion work = COMPLETION_INITIALIZER(work) 


and expands to the definition of the completion structure. This structure is defined in the 
include/linux/completion.h and presents completions concept. Completions is a code 
synchronization mechanism which provides race-free solution for the threads that must wait 
for some process to have reached a point or a specific state. Using completions consists of 
three parts: The first is definition of the complete structure and we did it with the 
DECLARE_COMPLETION . The second is call of the wait_for_completion . After the call of this 
function, a thread which called it will not continue to execute and will wait while other thread 
did not call complete function. Note that we call wait_for_completion with the 
kthreadd_done in the beginning of the kernel_init_freeable 


wait_for_completion(&kthreadd_done) ; 


And the last step is to call complete function as we saw it above. After this the 
kernel_init_freeable function will not be executed while kthreadd thread will not be set. 
After the kthreadd was set, we can see three following functions in the rest_init : 


init_idle_bootup_task(current); 
schedule_preempt_disabled(); 
cpu_startup_entry(CPUHP_ONLINE); 


The first init_idle_bootup_task function from the kernel/sched/core.c sets the Scheduling 
class for the current process ( idle class in our case): 


void init_idle_bootup_task(struct task_struct *idle) 


idle->sched_class = &idle_sched_class; 


where idle class is a low task priority and tasks can be run only when the processor 
doesn't have anything to run besides this tasks. The second function 
schedule_preempt_disabled disables preemptin idle tasks. And the third function 
cpu_startup_entry is defined in the kernel/sched/idle.c and calls cpu_idle_loop from the 
kernel/sched/idie.c. The cpu_idle_loop function works as process with pip = 9 and works 
in the background. Main purpose of the cpu_idle_loop is to consume the idle CPU cycles. 
When there is no process to run, this process starts to work. We have one process with 
idle scheduling class (we just set the current task to the idle with the call of the 
init_idle_bootup_task function), so the idle thread does not do useful work but just 
checks if there is an active task to switch to: 


static void cpu_idle_loop(void) 


{ 


while (1) { 
while (!need_resched()) { 


More about it will be in the chapter about scheduler. So for this moment the start_kernel 
calls the rest_init function which spawns an init ( kernel_init function) process and 
become idle process itself. Now is time to look on the kernel_init . Execution of the 
kernel_init function starts from the call of the kernel_init_freeable function. The 
kernel_init_freeable function first of all waits for the completion of the kthreadd setup. | 
already wrote about it above: 


wait_for_completion(&kthreadd_done); 


After this we set gfp_allowed_mask to __GFP_BITS_MASK which means that system is already 
running, set allowed cpus/mems to all CPUs and NUMA nodes with the set_mems_allowed 
function, allow init process to run on any CPU with the set_cpus_allowed_ptr , set pid for 
the cad or Ctrl-Alt-Delete , do preparation for booting of the other CPUs with the call of 


the smp_prepare_cpus , Call early initcalls with the do_pre_smp_initcalls , initialize smp with 
the smp_init and initialize lockup detector with the call of the lockup_detector_init and 
initialize scheduler with the sched_init_smp . 


After this we can see the call of the following functions - do_basic_setup . Before we will call 
the do_basic_setup function, our kernel already initialized for this moment. As comment 
says: 


Now we can finally start doing some real work.. 


The do_basic_setup will reinitialize couset to the active CPUs, initialize the khelper - which 
is a kernel thread which used for making calls out to userspace from within the kernel, 
initialize tmpfs, initialize drivers subsystem, enable the user-mode helper workqueue and 
make post-early call of the initcalls . We can see opening of the dev/console and dup 
twice file descriptors from o to 2 afterthe do_basic_setup : 


if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) 
pr_err("Warning: unable to open an initial console.\n"); 


(void) sys_dup(0); 
(void) sys_dup(0); 


We are using two system calls here sys_open and sys_dup . In the next chapters we will 
see explanation and implementation of the different system calls. After we opened initial 
console, we check that rdinit= option was passed to the kernel command line or set 
default path of the ramdisk: 


if (!ramdisk_execute_command) 
ramdisk_execute_command = "/init"; 


Check user's permissions for the ramdisk and call the prepare_namespace function from the 
init/do_mounts.c which checks and mounts the initrd: 


if (sys_access((const char __user *) ramdisk_execute_command, 9) != 0) { 
ramdisk_execute_command = NULL; 
prepare_namespace(); 


This is the end of the kernel_init_freeable function and we need return to the 
kernel_init . The next step after the kernel_init_freeable finished its execution is the 
async_synchronize_full . This function waits until all asynchronous function calls have been 
done and after it we will call the free_initmem which will release all memory occupied by the 


initialization stuff which located between _ init begin and _ init_end . After this we 
protect .rodata withthe mark_rodata_ro and update state of the system from the 
SYSTEM_BooTING to the 


system_state = SYSTEM RUNNING, 


And tries to run the init process: 


if (ramdisk_execute_command) { 
ret = run_init_process(ramdisk_execute_command); 
if (!ret) 
return 0; 
pr_err("Failed to execute %s (error %d)\n", 
ramdisk_execute_command, ret); 


First of all it checks the ramdisk_execute_command which we set inthe kernel_init_freeable 
function and it will be equal to the value of the rdinit= kernel command line parameters or 

/init by default. The run_init_process function fills the first element of the argv_init 
array: 


static const char *argv_init[MAX_INIT_ARGS+2] = { "init", NULL, }; 


which represents arguments of the init program and call do_execve function: 


argv_init[0] = init_filename; 

return do_execve(getname_kernel(init_filename), 
(const char __user *const __user *)argv_init, 
(const char __user *const __user *)envp_init); 


The do_execve function is defined in the include/linux/sched.h and runs program with the 
given file name and arguments. If we did not pass rdinit= option to the kernel command 
line, kernel starts to check the execute_command which is equal to value of the init= kernel 
command line parameter: 


if (execute_command) { 
ret = run_init_process(execute_command) ; 
if (!ret) 
return 0; 
panic("Requested init %s failed (error %d).", 
execute_command, ret); 


If we did not pass init= kernel command line parameter either, kernel tries to run one of 
the following executable files: 


if (!try_to_run_init_process("/sbin/init") || 
!try_to_run_init_process("/etc/init") || 
!'try_to_run_init_process("/bin/init") || 
!try_to_run_init_process("/bin/sh")) 
return o 


Otherwise we finish with panic: 


panic("No working init found. Try passing init= option to kernel. " 
"See Linux Documentation/init.txt for guidance."); 


That's all! Linux kernel initialization process is finished! 


Conclusion 


It is the end of the tenth part about the linux kernel initialization process. It is not only the 

tenth part, but also is the last part which describes initialization of the linux kernel. As | 
wrote in the first part of this chapter, we will go through all steps of the kernel initialization 
and we did it. We started at the first architecture-independent function - start_kernel and 
finished with the launch of the first init process in the our system. | skipped details about 
different subsystem of the kernel, for example | almost did not cover scheduler, interrupts, 
exception handling, etc. From the next part we will start to dive to the different kernel 
subsystems. Hope it will be interesting. 


If you have any questions or suggestions write me a comment or ping me at twitter. 


Please note that English is not my first language, And | am really sorry for any 
inconvenience. If you find any mistakes please send me PR to linux-insides. 


Links 


e SLAB 

e xsave 

e FPU 

e Documentation/security/credentials.txt 
e Documentation/x86/x86_64/mm 

e RCU 

e VFS 


初始 化 结束 


e inode 

e proc 

e man proc 

e Sysctl 

e ftrace 

e cgroup 

e CPU hotplug documentation 
e completions - wait for completion handling 
e NUMA 

e cpus/mems 

è initcalls 

e Tmpfs 

e initrd 

e panic 

e Previous part 
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中 断 和 中 断 处 理 


在 linux 内 核 中 你 会 发 现 很 多 关于 中 断 和 蜡 党 处理 的 话题 


中 断 和 中 断 处 理 第 一 部 分 - 描述 中 断 处 理 主题 

深入 Linux 内 核 中 的 中 断 - 这 部 分 开始 描述 和 初步 步骤 相关 的 中 断 和 出 常 处 理 。 

初步 中 断 处 理 - 描述 初步 中 断 处 理 。 

中 断 处 理 - fourth part describes first non-early interrupt handlers. 

异常 处 理 的 实现 - 一 些 异 常 处 理 的 实现 ， 比 如 双重 错误 、 除 零 等 等 。 

处 理 不 可 屏蔽 中 断 - 描述 了 如 何 处 理 不 可 屏蔽 的 中 断 和 剩 下 的 一 些 与 特定 架构 相关 的 中 
深入 外 部 硬件 中 断 - 这 部 分 讲述 了 关于 处 理 外 部 硬件 中 断 的 一 些 早期 初始 化 代码 。 
IRQs 的 非 早 期 初始 化 - 这 部 分 讲述 了 处 理 外 部 硬件 中 断 的 非 早 期 初始 化 代码 。 

Softirg, Tasklets and Workqueues - 这 部 分 讲述 了 softirqs、tasklets 和 workqueues 的 内 
最 后 一 部 分 - 这 是 中 断 和 中 断 处 理 的 最 后 一 部 分 ， 并 且 我 们 将 会 看 到 一 个 真实 的 硬件 驱动 
fo P B o 


中 断 和 中 断 处 理 Part 1. 


Introduction 


这 是 linux 内 核 揭 密 这 本 书 最 新 章节 的 第 一 部 分 。 我 们 已 经 在 这 本 书 前 面 的 章节 中 走 过 了 漫长 
的 道路 。 从 内 核 初 始 化 的 第 一 步 开始 ， 结 束 于 第 一 个 init 程序 的 启动 。 我 们 见证 了 一 系列 
与 各 种 内 核子 系统 相关 的 初始 化 步 又， 但 是 我 们 并 没有 深入 这 些 子 系统 。 在 这 一 章 中 ， 我 们 
将 会 试 着 去 了 解 这 些 内 核子 系统 是 如 何 工作 和 实现 的 。 就 像 你 在 这 章 标题 中 看 到 的 ， 第 一 个 
子 系统 是 中 断 (interrupts) ° 


什么 是 中 断 ? 


我 们 已 经 在 这 本 书 的 很 多 地 方 听 到 过 中 断 (interrupts) 这 个 词 ， 也 看 到 过 很 多 关于 中 断 的 
例子 。 在 这 一 章 中 我 们 将 会 从 下 面 的 主题 开始 : 


e 什么 是 中 断 (interrupts) ? 
o 什么 是 中 断 处 理 (interrupt handlers) ? 


我 们 将 会 继续 深入 探讨 中 断 的 细节 和 Linux 内 核 如 何 处 理 这 些 中 断 。 


所 以 ， 首 先 什么 是 中 断 ? 中 断 就 是 当 软 件 或 者 硬件 需要 使 用 CPU 时 引发 的 事件 (event) ° 
比如 ， 当 我 们 在 键盘 上 按 下 一 个 键 的 时 候 ， 我 们 下 一 步 期 望 做 什么 2 操作 系统 和 电脑 应 该 怎 
么 做 ?做 一 个 简单 的 假设 ， 每 一 个 物理 硬件 都 有 一 根 连接 CPU 的 中 断 线 ， 设 备 可 以 通过 它 对 
CPU 发 起 中 断 信 号 。 但 是 中 断 信 号 并 不 是 直接 发 送 给 CPU。 在 老 机 器 上 中 断 信 号 发 送 给 PIC 
， 它 是 一 个 顺序 处 理 各 种 设备 的 各 种 中 断 请 求 的 芯片 。 在 新 机 器 上 ， 则 是 高 级 程序 中 断 控 制 
# (Advanced Programmable Interrupt Controller) 做 这 件 事情 ， 即 我 们 熟知 的 APIC 。 一 个 
APIC 包括 两 个 独立 的 设备 : 


@ Local APIC 


@ I/O APIC 


第 一 个 设备 - Local APIC 存在 于 每 个 CPU 核心 中 ，Local APIC 负责 处 理 特定 于 CPU 的 中 断 
配置 。Local APIC 常 被 用 于 管理 来 自 APIC 时 钟 (APIC-timer) 、 热 敏 元 件 和 其 他 与 |/O 设备 
连接 的 设备 的 中 断 。 


第 二 个 设备 - r/o APIC 提供 了 多 核 处 理 器 的 中 断 管理 。 它 被 用 来 在 所 有 的 CPU 核心 中 分 发 
外 部 中 断 。 更 多 关于 local 和 VO APIC 的 内 容 将 会 在 这 一 节 的 下 面 讲 到 。 就 如 你 所 知道 的 ， 

中 断 可 以 在 任何 时 间 发 生 。 当 一 个 中 断 发 生 时 ， 操 作 系 统 必 须 立 刻 处 理 它 。 但 是 处 理 一 个 中 断 
是 什么 意思 呢 ? 当 一 个 中 断 发 生 时 ， 操 作 系 统 必 须 确保 下 面 的 步 又 顺序 : 


。 内 核 必须 暂停 执行 当前 进程 (取代 当前 的 任务 ) : 
。 内 核 必须 搜索 中 断 处 理 程序 并 且 转 交 控制 权 (执行 中 断 处 理 程序 ) ; 


e 中 断 处 理 程序 结束 之 后 ， 被 中 断 的 进程 能 够 恢复 执行 。 


当然 ， 在 这 个 中 断 处 理 程序 中 会 涉及 到 很 多 错综复杂 的 过 程 。 但 是 上 面 3 条 是 这 个 程序 的 基 


每 个 中 断 处 理 程序 的 地 址 都 保存 在 一 个 特殊 的 位 置 ， 这 个 位 置 被 称 为 “中断 描述 符 表 (Interrupt 
Descriptor Table) 或 者 IDT 。 处 理 器 使 用 一 个 唯一 的 数字 来 识别 中 断 和 异常 的 类 型 ， 这 个 
数字 被 称 为 ”中 断 标识 码 (vector number) 。 一 个 中 断 标识 码 就 是 一 个 IDT 的 标识 。 中 断 标识 
码 范围 是 有 限 的 ， 从 o 到 255 。 你 可 以 在 Linux 内 核 源 码 中 找到 下 面 的 中 断 标 识 码 范 围 检 
查 代 码 : 


BUG_ON((unsigned)n > OxFF); 


你 可 以 在 Linux 内 核 源 码 中 关于 中 断 设 置 的 地 方 找到 这 个 检查 (例如 : set_intr_gate , void 
set_system_intr_gate 在 arch/x86/include/asm/desc.h 中 )。 从 o 到 31 的 32 个 中 断 标识 码 
被 处 理 器 保留 ， 用 作 处 理 架构 定义 的 异常 和 中 断 。 你 可 以 在 Linux 内 核 初 始 化 程序 的 第 二 部 
分 - 早期 中 断 和 异常 处 理 中 找到 这 个 表 和 关于 这 些 中 断 标 识 码 的 描述 。 从 32 到 255 的 中 
断 标 识 码 设计 为 用 户 定义 中 断 并 且 不 被 系统 保留 。 这 些 中 断 通常 分 配给 外 部 O 设备 ， 使 这 些 
设备 可 以 发 送 中 断 给 处 理 器 。 
现在 ， 我 们 来 讨论 中 断 的 类 型 。 笼 统 地 来 讲 ， 我 们 可 以 把 中 断 分 为 两 个 主要 类 型 : 

。 外 部 或 者 硬件 引起 的 中 断 ; 

© 软件 引起 的 中 断 。 
第 一 种 类 型 - 外 部 中 断 ， 由 Local APIC 或 者 与 Local APIC 连接 的 处 理 器 针脚 接收 。 第 二 种 
类 型 - 软件 引起 的 中 断 ， 由 处 理 器 自身 的 特殊 情况 引起 (有 时 使 用 特殊 架构 的 指令 )。 一 个 常见 
的 关于 特殊 情况 的 例子 就 是 除 零 。 另 一 个 例子 就 是 使 用 系统 调用 (syscall) 退出 程序 。 
就 如 之 前 提 到 过 的 ， 中 断 可 以 在 任何 时 间 因 为 超出 代码 和 CPU 控制 的 原因 而 发 生 。 另 一 方 
面 ， 异 常 和 程序 执行 同步 (synchronous) ， 并 且 可 以 被 分 为 3 类 : 

e 故障 (Faults ) 

e Aa (Traps) 

e 终止 (Aborts ) 

故障 是 在 执行 一 个 “不 完善 的 "指令 (可 以 在 之 后 被 修正 ) 之 前 被 报告 的 异常 。 如 果 发 生 了 ， 
它 允 许 被 中 断 的 程序 继续 执行 。 
接 下 来 的 陷入 是 一 个 在 执行 了 陷入 指令 后 立刻 被 报告 的 异常 。 陷 入 同样 允许 被 中 断 的 程序 
继续 执行 ， 就 像 故障 一 样 。 


的 终止 是 一 个 从 不 报告 引起 异常 的 精确 指令 的 异常 ， 并 且 不 允许 被 中 断 的 程序 继续 执 


oy 


我 们 已 经 从 前 面 的 部 分 知道 ， 中 断 可 以 分 为 ”可 屏蔽 的 (maskable) 和 不 可 屏蔽 的 (non- 
maskable) 。 可 屏蔽 的 中 断 可 以 被 阻塞 ， 使 用 x86 64 的 指令 - sti 和 cli 。 我 们 可 以 在 
Linux 内 核 代 码 中 找到 他 们 : 


static inline void native_irq_disable(void) 


{ 


asm volatile("cli": : :“memory”"); 


and 


static inline void native_irq_enable(void) 
{ 


asmvollabasle(stei ss memomy ji 


这 两 个 指令 修改 了 在 中 断 寄存 器 中 的 IF 标识 位 。 sti 指令 设置 IF 标识 ，cli 指令 清 
除 这 个 标识 。 不 可 屏蔽 的 中 断 总 是 被 报告 。 通 常 ， 任 何 硬件 上 的 失败 都 映射 为 不 可 屏蔽 中 
WT o 

如 果 多 个 异常 或 者 中 断 同 时 发 生 ， 处 理 器 以 事先 设 定好 的 中 断 优先 级 处 理 他 们 。 我 们 可 以 定 
义 下 面 表 中 的 从 最 低 到 最 高 的 优先 级 : 


Hardware Reset and Machine Checks | 
- RESET | 
- Machine Check | 
Ee Ny oe anne is 
Trap on Task Switch | 
- T flag in TSS is set | 


External Hardware Interventions | 
- FLUSH | 
- STOPCLK | 
| 
| 


Traps on the Previous Instruction | 
- Breakpoints | 


现在 我 们 了 解 了 一 些 关 于 各 种 类 
从 中 断 描述 符 


A ° IDT SART] 全 局 描述 符 表 (Global Descriptor Table) 


序 的 第 二 部 


表 (IDT) 


分 已 经 介 


Faults from Fetching Next Instruction 
Code-Segment Limit Violation 
Code Page Fault 


Faults from Decoding the Next Instruction 
Instruction length > 15 bytes 

Invalid Opcode 

Coprocessor Not Available 


Faults on Executing an Instruction 
Overflow 

Bound error 

Invalid TSS 

Segment Not Present 

Stack fault 

General Protection 

Data Page Fault 

Alignment Check 

x87 FPU Floating-point exception 
SIMD floating-point exception 
Virtualization exception 


型 的 中 断 和 异常 的 内 容 ， 是 时 候 转 到 更 实用 的 部 分 了 。 我 们 


开始 。 就 如 之 前 所 提 到 的 ， it 保存 了 中 断 和 异常 处 理 程序 的 入 口 指 


。 但 是 他 们 确实 有 一 些 不 同 ， IDT 的 表 项 被 称 为 
不 是 描述 符 (descriptors) 。 它 可 以 包含 下 面 的 一 种 : 


e +T] (Interrupt gates) 
。 任务 门 (Task gates) 
e 陷阱 门 (Trap gates) 


的 结构 ， 我 们 在 内 核 启 动 程 


门 (gates) ， 而 


在 x86 架构 中 ， 只 有 Iong mode 中 断 门 和 陷阱 门 可 以 在 x86_64 中 引用 。 就 像 全 局 描述 符 


xR ， 


中 断 描述 符 


让 我 们 回忆 在 内 核 启 


元 素 。 与 ”全 局 描述 符 表 不 一 样 的 是 ， 


te 在 xe 上 是 一 个 8 字 


动 程序 的 第 二 部 分 ， 全 局 描述 符 表 必须 包含 NULL 描述 各 


节 数 组 门 ， 而 在 x86_64 上 是 一 个 16 字 节 数组 门 。 


竺 作为 它 的 第 一 个 


中 断 描述 符 表 的 第 一 个 元 素 可 以 是 一 个 门 。 它 并 不 是 强制 


要 求 的 。 上 比如， 你 可 能 还 记得 我 们 只 是 在 早期 的 章节 中 过 渡 到 保护 模式 时 用 NULL 门 加 载 过 


中 断 描 


WE 


TA: 


Ifa 
* Set up the IDT 


a 
static void setup_idt(void) 
{ 
static const struct gdt_ptr null_idt = {0, 0}; 
asm volatile("lidtl %0" : : "m" (null_idt)); 
} 


在 arch/x86/boot/pm.c? > 中 断 描 述 符 表 可 以 在 线性 地 址 空间 和 基 址 的 任何 地 方 被 加 载 ， 只 要 
在 x86 上 以 8 字 节 对 齐 ， 在 x86 64 上 以 16 字 节 对 齐 。 IDT 的 基 址 存储 在 一 个 特殊 的 寄 
存 器 -IDTR。 在 x86 上 有 两 个 指令 -协调 工作 来 修改 mmr 寄存 器 : 


e LIDT 


e SIDT 
第 一 个 指令 LIDT 用 来 加 载 IDT 的 基 址 ， 即 在 IDTR 的 指定 操作 数 。 第 二 个 指令 SIDT 用 


来 在 指定 操作 数 中 读 取 和 存储 IDTR 的 内 容 。 在 xe 上 mmr 寄存 器 是 48 人 位， 包含 了 下 
面 的 信息 : 


Ses eee sooo seme seacSs (SSeS se Sosa ses + 
| | | 
| Base address of the IDT | Limit of the IDT | 
| | | 
CS ces eames oS sermecesem oes esesoss Moree ooo aa + 
47 16 15 0 


让 我 们 看 看 setup_idt 的 实现 ， 我 们 准备 了 一 个 null idt ， 并 且 使 用 liat 指令 把 它 加 载 
到 IDTR 寄存 器 。 注 意 ， null idt 是 gdt_ptr 类 型 ， 后 者 定义 如 下 : 


struct gdt_ptr { 
u16 len; 
u32 ptr; 
} __attribute__((packed)); 


这 里 我 们 可 以 看 看 IDTR 结构 的 定义 ， 就 像 我 们 在 示意 图 中 看 到 的 一 样 ， 由 2 字 节 和 4 字 节 
( 共 48 位) 的 两 个 域 组 成 。 现 在 ， 让 我 们 看 看 mT 入 口 结构 体 ， 它 是 一 个 在 xe 中 被 称 
为 门 的 16 字 节 数组 。 它 拥有 下 面 的 结构 : 


Pea Seas Sass Sarees SAS SSS oe eee So See ne Sacre Sessa eens Sees Sosboepesseossssesossase + 
| | 
| Reserved | 
| | 
二 
95 64 
OE eon ne ena a A A e a a a a a + 


He a e eaa ea Ss a a a + 

63 48 47 46 44 42 39 34 32 

P + 

l l [WD le | | | | | | 

| Offset 31..16 | P | P | © |Type [© 060|0|0 | IST | 

| | li | el | 
Ep aN a a Sy ea ae yen A aN ee ay ae aes a De A eR dT a a + 

31 16 15 0 

He ee + 

| | | 

| Segment Selector | Offset 15..0 | 

| | | 

Hs + 


为 了 把 索引 格式 化 成 IDT 的 格式 ， 处 理 器 把 异常 和 中 断 向 量 分 为 16 个 级 别 。 处 理 器 处 理 异 党 
和 中 断 的 发 生 就 像 它 看 到 call 指令 时 处 理 一 个 程序 调用 一 样 。 处 理 器 使 用 中 断 或 异常 的 唯 
一 的 数字 或 ”中 断 标识 码 作为 索引 来 寻找 对 应 的 poeta 的 条 目 。 现 在 让 我 们 更 近 距 离 地 
看 看 IDT 条 目 。 


就 像 我 们 所 看 到 的 一 样 ， 在 表 中 的 IDT 条 目 由 下 面 的 域 组 成 : 


e 0-15 bits- 段 选择 器 偏 移 ， 处 理 器 用 它 作 为 中 断 处 理 程序 的 入 口 指针 基 址 ; 
e 16-31 bits - 段 选择 器 基 址 ， 包 含 中 断 处 理 程序 入 口 指针 ; 

e ist -在 x86 64 上 的 一 个 新 的 机 制 ， 下 面 我 们 会 介绍 它 ; 

© DPL - 描述 符 特 权 级 ; 

。 p - 段 存在 标志 ; 

e 48-63 bits- 中 断 处 理 程序 基 址 的 第 二 部 分 ; 

e 64-95 bits - 中 断 处 理 程序 基 址 的 人 分 ; 

e 96-127 bits - CPU 保留 位 . 


Type 域 描述 了 IDT 条 目的 类 型 。 有 三 种 不 同 的 中 断 处 理 程序 : 


e +87] (Interrupt gate ) 
e 陷入 门 (Trap gate) 
。 任务 门 (Task gate) 


IST 或 者 说 是 Interrupt Stack Table 是 x86 64 中 的 新 机 制 ， 它 用 来 代替 传统 的 栈 切 换 机 
制 。 之 前 的 x86 架构 提供 的 机 制 可 以 在 响应 中 断 时 自动 切换 栈 帧 。 IST 是 x86 栈 切 换 模 
式 的 一 个 修改 版 ， 在 它 使 能 之 后 可 以 无 条 件 地 切换 栈 ， 并 且 可 以 被 任何 与 确定 中 断 〈 我 们 将 
在 下 面 介绍 它 ) 关联 的 IDT 条 目 中 的 中 断 使 能 。 从 这 里 可 以 看 出 ， ist 并 不 是 所 有 的 中 断 
必须 的 ， 一 些 中 断 可 以 继续 使 用 传统 的 栈 切 换 模式 。 IST 机 制 在 任务 状态 段 (Task State 
Segment) 或 者 Tss 中 提供 了 7 个 IST 指针 。 tss 是 一 个 包含 进程 信息 的 特殊 结构 ， 用 
来 在 执行 中 断 或 者 处 理 Linux 内 核 异 常 的 时 候 做 栈 切 换 。 每 一 个 指针 都 被 IDT 中 的 中 断 门 引 
用 。 


中 断 描述 符 表 使 用 gate_desc 的 数组 描述 : 


extern gate desc idt_table[]; 


gate_desc 定义 如 下 : 


#ifdef CONFIG_X86_64 
typedef struct gate_struct64 gate_desc; 
#endif 


gate_structe4 定义 如 下 : 


struct gate_struct64 { 
U16 offset_low; 
u16 segment; 
unszogned ist kig, PAS Tele) Bye type S tole, 2 [og ale 
u16 offset_middle; 
u32 offset_high; 
u32 zeroi; 
} __attribute__((packed)); 


在 x86_64 架构 中 ， 每 一 个 活动 的 线程 在 Linux 内 核 中 都 有 一 个 很 大 的 栈 。 这 个 栈 的 大 小 由 
THREAD SIZE 定义， 而 且 与 下 面 的 定义 相等 : 


#define PAGE_SHIFT 12 
#define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT) 


#define THREAD_SIZE_ORDER (2 + KASAN_STACK_ORDER) 
#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE ORDER) 


PAGE_SIZE 是 4096 字 节 ， THREAD SIZE ORDER 的 值 依赖 于 KASAN_STACK_ORDER 。 就 像 我 们 
看 到 的 ， KASAN_STACK 依赖 于 coNFIG KASAN 内 核 配 置 参数 ， 它 定义 如 下 : 


#ifdef CONFIG KASAN 

#define KASAN_STACK_ORDER 1 
#else 

#define KASAN_STACK_ORDER 0 
#endif 


kasan 是 一 个 运行 时 内 存 调 试 嚣 。 所 以 ， 如 果 CONFIG_KASAN 被 禁用 ， THREAD SIZE 是 
16384 3 如 果 内 核 配置 选项 打开 ， THREAD_SIZE 的 值 是 32768 。 这 块 栈 空间 保存 着 有 用 的 
数据 ， 只 要 线程 是 活动 状态 或 者 僵尸 状态 。 但 是 当 线 程 在 用 户 空间 的 时 候 ， 这 个 内 核 栈 是 空 
的 ， 除 非 thread_info 结构 (关于 这 个 结构 的 详细 信息 在 Linux 内 核 初 始 程序 的 第 四 部 分 ) 
在 这 个 栈 空间 的 底部 。 活 动 的 或 者 僵尸 线程 并 不 是 在 他 们 栈 中 的 唯一 的 线程 ， 与 每 一 个 CPU 
关联 的 特殊 栈 也 存在 于 这 个 空间 。 当 内 核 在 这 个 CPU 上 执行 代码 的 时 候 ， 这 些 栈 处 于 活动 状 
态 ; 当 在 这 个 CPU 上 执行 用 户 空间 代码 时 ， 这 些 栈 不 包含 任何 有 用 的 信息 。 每 一 个 CPU 也 
有 一 个 特殊 的 per-cpu 栈 。 首 先是 给 外 部 中 断 使 用 的 ”中断 栈 (interrupt stack) ° 它 的 大 小 定 
义 如 下 : 


#define IRQ_STACK_ORDER (2 + KASAN_STACK_ORDER) 
#define IRQ_STACK_SIZE (PAGE_SIZE << IRQ_STACK_ORDER) 


或 者 是 16384 字 节 。 Per-cpu 的 中 断 栈 在 x86_64 架构 中 使 用 irq_stack_union 联合 描述 : 


union irq_stack_union { 
char irg_stack[IRQ_STACK_SIZE]; 


struct { 
char gs_base[40]; 
unsigned long stack_canary; 
}; 
}; 


第 一 个 irq_stack 域 是 一 个 16KB 的 数组 。 然 后 你 可 以 看 到 irq_stack_union 联合 包含 了 一 
个 结构 体 ， 这 个 结构 体 有 两 个 域 : 


e gs base - 总 是 指向 irqstack 联合 底部 的 gs 寄存 器 。 在 X86_64 中 ， per-cpu (更 
多 关于 per-cpu 变量 的 信息 可 以 阅读 特定 的 章节 ) 和 stack canary 共享 gs 寄存 器 9 
所 有 的 per-cpu 标志 初始 值 为 零 ， 并 且 gs 指向 per-cpu 区 域 的 开始 。 你 已 经 知道 段 内 
存 模式 已 经 废除 很 长 时 间 了 ， 但 是 我 们 可 以 使 用 特殊 模块 寄存 器 (Model specific 
registers) 给 这 两 个 段 寄 存 器 - fs 和 gs 设置 基 址 ， 并 且 这 些 寄存 器 仍然 可 以 被 用 作 
地 址 寄存 器 。 如 果 你 记得 Linux 内 核 初始 程序 的 第 一 部 分 ， 你 会 记 起 我 们 设置 了 gs F 


movl $MSR_GS_BASE, %ecx 


movl initial_gs(%rip),%eax 
movl initial_gs+4(%rip),%edx 
wrmsr 


initial_gs 指向 irq_stack_union : 


GLOBAL (initial_gs) 
. quad INIT_PER_CPU_VAR(irg_stack_union) 


e stack_canary - Stack canary 对 于 中 断 栈 来 说 是 一 个 用 来 验证 栈 是 否 已 经 被 修改 的 BR 
护 者 (stack protector) ° gs_base 是 一 个 40 字 节 的 数组 ， occ 要 求 stack canary 在 被 
修正 过 的 偏 移 量 上 ， 并 且 gs 的 值 在 x86 64 架构 上 必须 是 40 ， 在 x86 架构 上 必须 


是 20 ° 


irq_stack_union 是 percpu 的 第 一 个 数据 ， 我 们 可 以 在 System,map 中 看 到 它 : 


0000000000000000 D __per_cpu_start 
0000000000000000 D irq_stack_union 
0000000000004000 d exception_stacks 
0000000000009000 D gdt_page 


我 们 可 以 看 到 它 在 代码 中 的 定义 : 


DECLARE_PER_CPU_FIRST(union irq_stack_union, irq_stack_union) _ visible; 


现在 ， 是 时 候 来 看 irq_stack_union 的 初始 化 过 程 了 。 除 了 arg stack_union 的 定义 ， 我 们 
可 以 在 arch/x86/include/asm/processor.h 中 查看 下 面 的 per-cpu 变量 


DECLARE_PER_CPU(char *, irq_stack_ptr); 
DECLARE_PER_CPU(unsigned int, irq count); 


第 一 个 就 是 irq_stack_ptr 。 从 这 个 变量 的 名 字 中 可 以 知道 ， 它 显然 是 一 个 指向 这 个 栈 顶 的 
指针 。 第 二 个 irq count 用 来 检查 CPU 是 否 已 经 在 中 断 栈 。 irq_stack_ptr 的 初始 化 
在 arch/x86/kernel/setup_percpu.c 的 setup_per_cpu_areas 函数 中 : 


void __init setup_per_cpu_areas(void) 


{ 


#ifdef CONFIG X86_64 
for_each_possible_cpu(cpu) { 


per_cpu(irq_stack_ptr, cpu) = 
per_cpu(irq_stack_union.irq_stack, cpu) + 
IRQ_STACK_SIZE - 64; 


#endif 


现在 ， 我 们 一 个 一 个 查看 所 有 CPU’ # HUB irq_stack_ptr 。 事 实证 明 它 等 于 中 断 栈 的 顶 
减 去 64 。 为 什么 是 64 ? TODO [arch/x86/kernel/cpu/common.c] 代码 如 下 : 


void load_percpu_segment(int cpu) 


{ 


loadsegment(gs, 0); 
wrmsrl(MSR_GS_BASE, (unsigned long)per_cpu(irq_stack_union.gs_base, cpu)); 


就 像 我 们 所 知道 的 一 样 gs 寄存 器 指向 中 断 栈 的 栈 底 : 


movl $MSR_GS_BASE, %ecx 


movl initial_gs(%rip),%eax 
movl initial_gs+4(%rip),%edx 
wrmsr 


GLOBAL (initial_gs) 
. quad INIT_PER_CPU_VAR(irg_stack_union) 


现在 我 们 可 以 看 到 wrmsr 指令 ， 这 个 指令 从 edx:eax 加 载 数据 到 被 ecx 指向 的 MSR 宁 存 
器 )。 在 这 里 MSR 寄 存 器 是 MsR_GS_BASE ， 它 保存 了 被 gs 寄存 器 指向 的 内 存 段 的 基 
> edx:eax 指向 initial gs 的 地 址 ， 它 就 是 irq_stack_union 的 基 址 。 
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我 们 还 知道 ， x86 64 有 一 个 叫 中 断 栈 表 (Interrupt Stack Table) 或 者 IST 的 组 件 ， 当 发 
生 不 可 屏蔽 中 断 、 双 重 错误 等 等 的 时 候 ， 这 个 组 件 提供 了 切换 到 新 栈 的 功能 。 这 可 以 到 达 7 个 
IST per-cpu 入 口 。 其 中 一 些 如 下 ; There can be up to seven ist entries per-cpu. Some of 
them are: 


@ DOUBLEFAULT_STACK 
@ NMI_STACK 
@ DEBUG_STACK 


e MCE_STACK 
或 者 


#define DOUBLEFAULT_STACK 1 
#define NMI_STACK 2 

#define DEBUG_STACK 3 
#define MCE_STACK 4 


所 有 被 IST 切换 到 新 栈 的 中 断 门 描 述 符 都 由 set_intr_gate_ist 函数 初始 化 。 例 如 : 


set_intr_gate_ist(X86_TRAP_NMI, &nmi, NMI_STACK); 


set_intr_gate_ist(X86_TRAP_DF, &double_fault, DOUBLEFAULT_STACK) ; 


其 中 anmi 和 &double fault 是 中 断 函 数 的 入 口 地 址 : 


asmlinkage void nmi(void); 
asmlinkage void double fault(void); 


定义 在 arch/x86/kernel/entry_64.S F 


idtentry double_fault do_double_fault has_error_code=1 paranoid=2 


ENTRY (nmi) 


END (nmi) 


当 一 个 中 断 或 者 异常 发 生 时 ， 新 的 ss 选择 器 被 强制 置 为 NULL ， 并 且 ss 选择 器 的 rpl 
域 被 设置 为 新 的 cpl oA ss 、 rsp 、 寄 存 器 标志 、 cs > rip 被 压 入 新 栈 。 在 64 位 模 
型 下 ， 中 断 栈 帧 大 小 固定 为 8 字 节 ， 所 以 我 们 可 以 得 到 下 面 的 栈 : 


Error code 


下 十 
| | 
| SS | 40 
| RSP | 32 
| RFLAGS | 24 
| CS | 16 
| RIP | 8 
| | 
| | 


如 果 在 中 断 门 中 IST ATÆ 6， 我 们 把 IST 读 到 rsp 中 。 如 果 它 关联 了 一 个 中 断 向 量 
着 误 码 ， 我 们 再 把 这 个 错误 码 压 入 栈 。 如 果 中 断 向 量 没有 错误 码 ， 就 继续 并 且 把 虚拟 错误 码 
压 入 栈 。 我 们 必须 做 以 上 的 步骤 以 确保 栈 一 致 性 。 接 下 来 我 们 从 门 描述 符 中 加 载 段 选择 器 域 
到 CS 寄存 器 中 ， 并 且 通 过 验证 第 21 位 的 值 来 验证 目标 代码 是 一 个 64 位 代码 段 ， 例 如 L 
位 在 全 局 描述 符 表 (Global Descriptor Table) 。 最 后 我 们 从 门 描述 符 中 加 载 偏 移 域 到 rip 
Po rip 是 中 断 处 理 函 数 的 入 口 指针 。 然 后 中 断 函 数 开始 执行 ， 在 中 断 函 数 执行 结束 后 ， 它 
必须 通过 iret 指令 把 控制 权 交 还 给 被 中 断 进 程 。 iret 指令 无 条 件 地 弹出 栈 指 针 

( ss:rsp ) 来 恢复 被 中 断 的 进程 ， 并 且 不 会 依赖 于 cpl 改变 。 


这 就 是 中 断 的 所 有 过 程 。 


总 结 


名 
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KF Linux 内 核 的 中 断 和 中 断 处 理 的 第 一 部 分 至 此 结束 。 我 们 初步 了 解 了 一 些 理论 和 与 中 断 
和 异常 相关 的 初始 化 条 件 。 在 下 一 部 分 ， 我 会 接着 深入 了 解 中 断 和 中 断 处 理 - RRA T Bee 
实 的 样子 。 

如 果 你 有 任何 问题 或 建议 ， 请 给 我 发 评论 或 者 给 我 发 Twitter 。 

请 注意 美语 并 不 是 我 的 母语 ， 我 为 任何 表达 不 清楚 的 地 方 感到 抱歉 。 如 果 你 发 现任 何 错误 请 
发 PR 到 linux-insides ° ($4 : 翻译 问题 请 发 PR 到 linux-insides-cn) 
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Interrupts and Interrupt Handling. Part 2. 


Start to dive into interrupt and exceptions 
handling in the Linux kernel 


We saw some theory about interrupts and exception handling in the previous part and as | 
already wrote in that part, we will start to dive into interrupts and exceptions in the Linux 
kernel source code in this part. As you already can note, the previous part mostly described 
theoretical aspects and in this part we will start to dive directly into the Linux kernel source 
code. We will start to do it as we did it in other chapters, from the very early places. We will 
not see the Linux kernel source code from the earliest code lines as we saw it for example in 
the Linux kerne! booting process chapter, but we will start from the earliest code which is 
related to the interrupts and exceptions. In this part we will try to go through the all interrupts 
and exceptions related stuff which we can find in the Linux kernel source code. 


If you've read the previous parts, you can remember that the earliest place in the Linux 

kernel x86 64 architecture-specific source code which is related to the interrupt is located in 

the arch/x86/boot/pm.c source code file and represents the first setup of the Interrupt 
Descriptor Table. It occurs right before the transition into the protected mode in the 
go_to_protected_mode function by the call of the setup_idt : 


void go_to_protecte de (void) 


{ 


setup_idt(); 


The setup_idt function is defined in the same source code file as the 
go_to_protected_mode function and just loads the address of the NULL interrupts descriptor 
table: 


static void setup_idt(void) 

{ 
static const struct gdt_ptr null_idt = {0, 0}; 
asm volatile("lidtl %0" : : "m" (null_idt)); 


where gdt_ptr represents a special 48-bit cpTr register which must contain the base 
address of the Global Descriptor Table 


struct gdt_ptr { 
U16 len; 
u32 ptr; 
} __attribute__((packed)); 


Of course in our case the gdt_ptr does not represent the cptr register, but IpTr since 
we set Interrupt Descriptor Table . You will not find an idt_ptr structure, because if it had 
been in the Linux kernel source code, it would have been the same as gdt_ptr but with 
different name. So, as you can understand there is no sense to have two similar structures 
which differ only by name. You can note here, that we do not fill the Interrupt Descriptor 
Table with entries, because it is too early to handle any interrupts or exceptions at this point. 
That's why we just fill the ror with NULL . 


After the setup of the Interrupt descriptor table, Global Descriptor Table and other stuff we 
jump into protected mode in the - arch/x86/boot/pmjump.S. You can read more about it in 
the part which describes the transition to protected mode. 


We already know from the earliest parts that entry to protected mode is located in the 
boot_params.hdr.code32_start and you can see that we pass the entry of the protected 
mode and boot_params to the protected_mode_jump in the end of the arch/x86/boot/pm.c: 


protected_mode_jump(boot_params.hdr.code32_start, 
(u32)&boot_params + (ds() << 4)); 


The protected_mode_jump is defined in the arch/x86/boot/pmjump.S and gets these two 
parameters inthe ax and dx registers using one of the 8086 calling conventions: 


GLOBAL (protected_mode_jump) 


.byte 0x66, Oxea # ljmpl opcode 


2: . long in_pm32 # offset 
.word __BOOT_CS # segment 


ENDPROC(protected_mode_jump) 


where in_pm32 contains a jump to the 32-bit entry point: 


GLOBAL(in_pm32) 
jmpl *%eax // %eax contains address of the `startup_32` 
ENDPROC(in_pm32) 


As you can remember the 32-bit entry point is in the arch/x86/boot/compressed/head_64.S 
assembly file, although it contains _64 in its name. We can see the two similar files in the 
arch/x86/boot/compressed directory: 


èe arch/x86/boot/compressed/head_32.S 


@ arch/x86/boot/compressed/head_64.S 


But the 32-bit mode entry point is the second file in our case. The first file is not even 
compiled for x86_64 . Let's look at the arch/x86/boot/compressed/Makefile: 


vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/head_$(BITS).o $(obj)/misc.o \ 


We can see here that head_* depends onthe $(BITS) variable which depends on the 
architecture. You can find it in the arch/x86/Makefile: 


ifeq ($(CONFIG_X86_32),y) 


BITS := 32 
else 

BITS := 64 
endif 


Now as we jumped on the startup_32 from the arch/x86/boot/compressed/head_64.S we 
will not find anything related to the interrupt handling here. The startup_32 contains code 
that makes preparations before the transition into long mode and directly jumps in to it. The 

long mode entry is located in startup_64 and it makes preparations before the kernel 
decompression that occurs in the decompress_kernel from the 
arch/x86/boot/compressed/misc.c. After the kernel is decompressed, we jump on the 

startup_64 from the arch/x86/kernel/nead_ 64.S. Inthe startup_64 we start to build 
identity-mapped pages. After we have built identity-mapped pages, checked the NX bit, 
setup the Extended Feature Enable Register (see in links), and updated the early Global 
Descriptor Table withthe i1gdt instruction, we need to setup gs register with the following 
code: 


movl $MSR_GS_BASE, %ecx 


movl initial_gs(%rip),%eax 
movl initial_gs+4(%rip),%edx 
wrmsr 


We already saw this code in the previous part. First of all pay attention on the last wrmsr 
instruction. This instruction writes data from the edx:eax registers to the model specific 
register specified by the ecx register. We can see that ecx contains $msr_cs_Base which 
is declared in the arch/x86/include/uapi/asm/msr-index.h and looks like: 


#define MSR_GS_BASE 0xc0000101 


From this we can understand that msr_cs_Base defines the number of the model specific 
register . Since registers cs , ds, es , and ss are not used in the 64-bit mode, their 
fields are ignored. But we can access memory over fs and gs registers. The model 
specific register provides a back door to the hidden parts of these segment registers and 
allows to use 64-bit base address for segment register addressed by the fs and gs . So 
the msr_cs_ Base is the hidden part and this part is mapped on the Gs.base field. Let's look 
onthe initial_gs : 


GLOBAL (initial_gs) 
. quad INIT_PER_CPU_VAR(irgq_stack_union) 


We pass irq _stack_union symbol to the INIT_PER_cPU_vAR macro which just concatenates 
the init_per_cpu_ prefix with the given symbol. In our case we will get the 
init_per_cpu__irq_stack_union symbol. Let's look at the linker script. There we can see 





following definition: 


#define INIT_PER_CPU(x) init_per_cpu__##x = x + __per_cpu_load 
INIT_PER_CPU(irg_stack_union); 


It tells us that the address of the init_per_cpu__irq_stack_union will be irq_stack_union + 





__per_cpu_load . Now we need to understand where init_per_cpu__irg_stack_union and 





__per_cpu_load are what they mean. The first irq_stack_union is defined in the 
arch/x86/include/asm/processor.h with the DECLARE_INIT_PER_CPU macro which expands to 
call the init_per_cpu_var macro: 


DECLARE_INIT_PER_CPU(irq_stack_union); 


#define DECLARE_INIT_PER_CPU(var) \ 
extern typeof(per_cpu_var(var)) init_per_cpu_var(var) 


#define init_per_cpu_var(var) init_per_cpu__##var 





If we expand all macros we will get the same init_per_cpu__irq_stack_union as we got after 
expanding the INIT_PER CPU macro, but you can note that it is not just a symbol, but a 
variable. Let's look at the typeof(per_cpu_var(var)) expression. Our var is 

irg_stack_union andthe per_cpu_var macro is defined in the 
arch/x86/include/asm/percpu.h: 


#define PER_CPU_VAR(var) %__percpu_seg: var 


where: 


#ifdef CONFIG_X86_64 
#define __percpu_seg gs 
endif 


So, we are accessing gs:irq_stack_union and getting its type whichis irq_union . Ok, we 
defined the first variable and know its address, now let's look at the second _ per cpu load 
symbol. There are a couple of per-cpu variables which are located after this symbol. The 
__per_cpu_load is defined in the include/asm-generic/sections.h: 


extern char __per_cpu_load[], __per_cpu_start[], __per_cpu_end[]; 


and presented base address of the per-cpu variables from the data area. So, we know the 
address of the irq stack union , __per_cpu_load and we know that 
init_per_cpu__irg_stack_union must be placed right after __per_cpu_load . And we can see 





it in the System.map: 


ffffffff819edo00 D __init_begin 
ffffffff819ed000 D __per_cpu_load 
ffffffff819ed000 A init_per_cpu__irq_stack_union 





Now we know about initial_gs , so let's look at the code: 


movl $MSR_GS_BASE, %ecx 


movl initial_gs(%rip),%eax 
movl initial_gs+4(%rip),%edx 
wrmsr 


Here we specified a model specific register with msr_6s_BASE , put the 64-bit address of the 
initial gs tothe edx:eax pair and execute the wrmsr instruction for filling the gs 
register with the base address of the init_per_cpu_irq_stack_union which will be at the 





bottom of the interrupt stack. After this we will jump to the C code on the 

x86_64_start_kernel from the arch/x86/kernel/nead64.c. In the xs86_64_start_kernel 
function we do the last preparations before we jump into the generic and architecture- 
independent kernel code and one of these preparations is filling the early Interrupt 
Descriptor Table with the interrupts handlers entries or early_idt_handlers . You can 
remember it, if you have read the part about the Early interrupt and exception handling and 
can remember following code: 


for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) 
set_intr_gate(i, early_idt_handlers[i]); 


load_idt((const struct desc_ptr *)&idt_descr); 


but | wrote Early interrupt and exception handling part when Linux kernel version was - 
3.18 . For this day actual version of the Linux kernel is 4.1.0-rc6é+ and Andy Lutomirski 
sent the patch and soon it will be in the mainline kernel that changes behaviour for the 
early_idt_handlers . NOTE While | wrote this part the patch already turned in the Linux 
kernel source code. Let's look on it. Now the same part looks like: 


for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) 
set_intr_gate(i, early_idt_handler_array[i]); 


load_idt((const struct desc_ptr *)&idt_descr); 


AS you can see it has only one difference in the name of the array of the interrupts handlers 
entry points. Now it is early_idt_handler_arry : 


extern const char early_idt_handler_array[NUM_EXCEPTION_VECTORS ] [EARLY_IDT_HANDLER_SIZ 
E]; 


where NUM_EXCEPTION_VECTORS and EARLY_IDT_HANDLER_SIZE are defined as: 


#define NUM_EXCEPTION_VECTORS 32 
#define EARLY_IDT_HANDLER_SIZE 9 


So, the early_idt_handler_array is an array of the interrupts handlers entry points and 

contains one entry point on every nine bytes. You can remember that previous 
early_idt_handlers was defined in the arch/x86/kernel/head_64.S. The 
early_idt_handler_array is defined in the same source code file too: 


ENTRY(early_idt_handler_array) 


ENDPROC(early_idt_handler_common) 


It fills early_idt_handler_arry with the .rept NUM_EXCEPTION_VECTORS and contains entry of 
the early_make_pgtable interrupt handler (more about its implementation you can read in 
the part about Early interrupt and exception handling). For now we come to the end of the 

x86_64 architecture-specific code and the next part is the generic kernel code. Of course 
you already can know that we will return to the architecture-specific code in the setup_arch 
function and other places, but this is the end of the x86 64 early code. 


Setting stack canary for the interrupt stack 


The next stop after the arch/x86/kernel/nead_64.S is the biggest start_kernel function 
from the init/main.c. If you've read the previous chapter about the Linux kernel initialization 
process, you must remember it. This function does all initialization stuff before kernel will 
launch first init process with the pid - 1 . The first thing that is related to the interrupts 
and exceptions handling is the call of the boot_init_stack_canary function. 


This function sets the canary value to protect interrupt stack overflow. We already saw a little 
some details about implementation of the boot_init_stack_canary in the previous part and 
now let's take a closer look on it. You can find implementation of this function in the 
arch/x86/include/asm/stackprotector.h and its depends on the coNFIG cc_ STACKPROTECTOR 
kernel configuration option. If this option is not set this function will not do anything: 


#ifdef CONFIG_CC_STACKPROTECTOR 


#else 
static inline void boot_init_stack_canary(void) 


} 
#endif 


If the coNFIG_cc_STACKPROTECTOR kernel configuration option is set, the 
boot_init_stack_canary function starts from the check stat irq _stack_union that represents 
per-cpu interrupt stack has offset equal to forty bytes from the stack_canary value: 


#ifdef CONFIG_X86_64 
BUILD_BUG_ON(offsetof(union irq_stack_union, stack_canary) != 40); 
#endif 


As we can read in the previous part the irq _stack_union represented by the following 
union: 


union irq_stack_union { 
char irg_stack[IRQ_STACK_SIZE]; 


SENCER 
char gs_base[40]; 
unsigned long stack_canary; 
}; 
}; 


which defined in the arch/x86/include/asm/processor.h. We know that union in the C 
programming language is a data structure which stores only one field in a memory. We can 
see here that structure has first field - gs_base Which is 40 bytes size and represents 
bottom of the irq_stack . So, after this our check with the BUILD_Buc_oN macro should end 
successfully. (you can read the first part about Linux kernel initialization process if you're 
interesting about the BuILD_BUG_oN macro). 


After this we calculate new canary value based on the random number and Time Stamp 
Counter: 


get_random_bytes(&canary, sizeof(canary)); 
tsc = native_read_tsc(); 
canary += tsc + (tsc << 32UL); 





and write canary value tothe irgq_stack_union with the this_cpu_write macro: 


this_cpu_write(irq_stack_union.stack_canary, canary); 


more about this_cpu_* operation you can read in the Linux kernel documentation. 


Disabling/Enabling local interrupts 


The next step in the init/main.c which is related to the interrupts and interrupts handling after 
we have set the canary value to the interrupt stack - is the call of the local irq disable 
macro. 


This macro defined in the include/linux/irqflags.h header file and as you can understand, we 
can disable interrupts for the CPU with the call of this macro. Let's look on its 
implementation. First of all note that it depends on the conFIG_TRACE_IRQFLAGS_SUPPORT 
kernel configuration option: 


#ifdef CONFIG_TRACE_IRQFLAGS_SUPPORT 


#define local_irq_disable() \ 
do { raw_local_irq_disable(); trace_hardirqs_off(); } while (0) 


#else 
#define local_irq_disable() do { raw_local_irq_disable(); } while (0) 
#endif 


They are both similar and as you can see have only one difference: the local_irq disable 

macro contains call of the trace_hardirqs_off When CONFIG_TRACE_IRQFLAGS_SUPPORT iS 

enabled. There is special feature in the lockdep subsystem - irq-flags tracing for tracing 
hardirq and softirq state. In our case lockdep subsystem can give us interesting 

information about hard/soft irqs on/off events which are occurs in the system. The 
trace_hardirqs_off function defined in the kernel/locking/lockdep.c: 


void trace_hardirqs_off(void) 
{ 
trace_hardirqs_off_caller(CALLER_ADDR®O) ; 


} 
EXPORT_SYMBOL (trace_hardirqs_off); 


and just calls trace_hardirgs_off_caller function. The trace_hardirqs_off_caller checks 
the hardirgs_enabled field of the current process and increases the 
redundant_hardirgs_off if call ofthe 1ocal_irq_disable was redundant or the 
hardirgs_off_events if it was not. These two fields and other lockdep statistic related fields 
are defined in the kernel/locking/lockdep_insides.h and located in the lockdep_stats 
structure: 


struct lockdep_stats { 


int softirqs_off_events; 
int redundant_softirqs_off; 
} 


If you will set coNFIG_DEBuG_LocKDEP kernel configuration option, the 
lockdep_stats_debug_show function will write all tracing information to the /proc/lockdep : 


static void lockdep_stats_debug_show(struct seq _file *m) 
{ 
#ifdef CONFIG_DEBUG_LOCKDEP 
unsigned long long hi1 = debug_atomic_read(hardirqs_on_events), 
hi2 = debug_atomic_read(hardirqs_off_events), 
hri = debug_atomic_read(redundant_hardirqs_on), 


seq_printf(m, " hardirq on events: %111lu\n", hit); 


seq_printf(m, " hardirq off events: 9015 ON EZ 
seq_printf(m, " redundant hardirq ons: ITELE nr D); 
#endif 


} 


and you can see its result with the: 


$ sudo cat /proc/lockdep 


hardirq on events: 12838248974 
hardirq off events: 12838248979 
redundant hardirq ons: 67792 
redundant hardirq offs: 3836339146 
softirq on events: 38002159 
softirq off events: 38002187 
redundant softirq ons: 0 


redundant softirq offs: 0 


Ok, now we know a little about tracing, but more info will be in the separate part about 
lockdep and tracing . You can see that the both local disable irq macros have the 

same part- raw local irq disable . This macro defined in the 

arch/x86/include/asm/irqflags.h and expands to the call of the: 


static inline void native_irq_disable(void) 
{ 

asmavola tele (ie n MEM OV 
} 


And you already must remember that cli instruction clears the IF flag which determines 
ability of a processor to handle an interrupt or an exception. Besides the local_irq_disable , 
as you already can know there is an inverse macro - local_irq_enable . This macro has the 
same tracing mechanism and very similar on the local irq enable , but as you can 
understand from its name, it enables interrupts with the sti instruction: 


static inline void native_irq_enable(void) 
{ 

asm volatile("sti": : :"memory"); 
} 


Now we know how local irq disable and local irq enable Work. lt was the first call of 
the local_irq_disable macro, but we will meet these macros many times in the Linux 
kernel source code. But for now we are in the start_kernel function from the init/main.c 
and we just disabled local interrupts. Why local and why we did it? Previously kernel 
provided a method to disable interrupts on all processors and it was called cli . This 
function was removed and now we have local_irq_{enabled,disable} to disable or enable 
interrupts on the current processor. After we've disabled the interrupts with the 
local_irq_disable macro, we set the: 


early_boot_irgqs_disabled = true; 


The early_boot_irqs_disabled variable defined in the include/linux/kernel.h: 


extern bool early_boot_irqs_disabled; 


and used in the different places. For example it used in the smp_call_function_many function 
from the kernel/smp.c for the checking possible deadlock when interrupts are disabled: 


WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled() 
&& !oops_in_progress && !early_boot_irqs_disabled) ; 


Early trap initialization during kernel 
initialization 


The next functions after the local_disable_irq are boot_cpu_init and page_address_init , 
but they are not related to the interrupts and exceptions (more about this functions you can 
read in the chapter about Linux kernel initialization process). The next is the setup_arch 
function. As you can remember this function located in the arch/x86/kernel/setup.c source 
code file and makes initialization of many different architecture-dependent stuff. The first 
interrupts related function which we can see in the setup_arch is the - early_trap_init 
function. This function defined in the arch/x86/kernel/traps.c and fills Interrupt Descriptor 
Table with the couple of entries: 


void __init early_trap_init(void) 
{ 
set_intr_gate_ist(X86_TRAP_DB, &debug, DEBUG_STACK); 
set_system_intr_gate_ist(X86_TRAP_BP, &int3, DEBUG_STACK); 
#ifdef CONFIG_X86_32 
set_intr_gate(X86_TRAP_PF, page_fault); 
#endif 
load_idt(&idt_descr); 





Here we can see calls of three different functions: 


@ set_intr_gate_ist 


@ set_system_intr_gate_ist 





@ set_intr_gate 


All of these functions defined in the arch/x86/include/asm/desc.h and do the similar thing but 
not the same. The first set_intr_gate_ist function inserts new an interrupt gate in the IDT. 
Let's look on its implementation: 


ate_ist(int n, void *addr, unsigned ist) 


static inline void set 


{ 
BUG_ON((unsigned)n > OxFF); 
_set_gate(n, GATE_INTERRUPT, addr, ©, ist, __KERNEL_CS); 


First of all we can see the check that n which is vector number of the interrupt is not 
greater than oxff or 255. We need to check it because we remember from the previous 
part that vector number of an interrupt must be between o and 255 . In the next step we 
can see the call of the _set_gate function that sets a given interrupt gate to the rpt table: 


static inline void _set_gate(int gate, unsigned type, void *addr, 
unsigned dpl, unsigned ist, unsigned seg) 


{ 
gate_desc s; 
pack_gate(&s, type, (unsigned long)addr, dpl, ist, seg); 
write_idt_entry(idt_table, gate, &s); 
write_trace_idt_entry(gate, &s); 

} 


Here we start from the pack_gate function which takes clean int entry represented by the 
gate_desc Structure and fills it with the base address and limit, Interrupt Stack Table, 
Privilege level, type of an interrupt which can be one of the following values: 


@ GATE_INTERRUPT 
@ GATE_TRAP 
@ GATE_CALL 


@ GATE_ TASK 


and set the present bit for the given IDT entry: 


static inline void pack_gate(gate_desc *gate, unsigned type, unsigned long func, 
unsigned dpl, unsigned ist, unsigned seg) 


{ 
gate->offset_low = PTR_LOW( func); 
gate->segment = __KERNEL_CS; 
gate->ist = ist; 
gate->p = ip 
gate->dpl = dpl; 
gate->zero0 = 0; 
gate->zero1 = 0; 
gate->type = type; 
gate->offset_middle = PTR_MIDDLE( func); 
gate->offset_high = PTR_HIGH(func); 
} 


After this we write just filled interrupt gate to the tpt with the write_idt_entry macro 
which expands to the native_write_idt_entry and just copy the interrupt gate to the 
idt_table table by the given index: 


#define write_idt_entry(dt, entry, g) native_write_idt_entry(dt, entry, g) 


static inline void native_write_idt_entry(gate_desc *idt, int entry, const gate_desc * 
gate) 


{ 
memcpy(&idt[entry], gate, sizeof(*gate)); 


where idt_table is just array of gate_desc : 


extern gate_desc idt_table[]; 


That's all. The second set_system_intr_gate_ist function has only one difference from the 





set_intr_gate_ist 


static inline void set_system_intr_gate_ist(int n, void *addr, unsigned ist) 


{ 
BUG_ON((unsigned)n > OxFF); 
_set_gate(n, GATE_INTERRUPT, addr, 0x3, ist, __KERNEL_CS); 


Do you see it? Look on the fourth parameter of the _set_gate .ltis ox3 . In the 
set_intr_gate it was oxo . We know that this parameter represent ppt or privilege level. 
We also know that o is the highest privilege level and 3 is the lowest.Now we know how 


set_system_intr_gate_ist , set_intr_gate_ist , set_intr_gate are work and we can return 





to the early_trap_init function. Let's look on it again: 


set_intr_gate_ist(X86_TRAP_DB, &debug, DEBUG_STACK); 
set_system_intr_gate_ist(X86_TRAP_BP, &int3, DEBUG_STACK); 





We settwo tpt entries forthe #pe interrupt and int3 . These functions takes the same 
set of parameters: 


e vector number of an interrupt; 
e address of an interrupt handler; 
e interrupt stack table index. 


That's all. More about interrupts and handlers you will know in the next parts. 


Conclusion 


It is the end of the second part about interrupts and interrupt handling in the Linux kernel. 
We saw the some theory in the previous part and started to dive into interrupts and 
exceptions handling in the current part. We have started from the earliest parts in the Linux 
kernel source code which are related to the interrupts. In the next part we will continue to 
dive into this interesting theme and will know more about interrupt handling process. 


If you have any questions or suggestions write me a comment or ping me at twitter. 


Please note that English is not my first language, And | am really sorry for any 
inconvenience. If you find any mistakes please send me PR to linux-insides. 
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Interrupts and Interrupt Handling. Part 3. 


Exception Handling 


This is the third part of the chapter about an interrupts and an exceptions handling in the 
Linux kernel and in the previous part we stopped at the setup_arch function from the 
arch/x86/kernel/setup.c source code file. 


We already know that this function executes initialization of architecture-specific stuff. In our 
case the setup_arch function does x86_64 architecture related initializations. The 

setup_arch is big function, and in the previous part we stopped on the setting of the two 
exceptions handlers for the two following exceptions: 


e #DB - debug exception, transfers control from the interrupted process to the debug 
handler; 
e #BP - breakpoint exception, caused by the int 3 instruction. 


These exceptions allow the xs6_64 architecture to have early exception processing for the 
purpose of debugging via the kgdb. 


As you can remember we set these exceptions handlers in the early_trap_init function: 


void imit early_trap_init(void) 

{ 
set_intr_gate_ist(X86_TRAP_DB, &debug, DEBUG_STACK); 
set_system_intr_gate_ist(X86_TRAP_BP, &int3, DEBUG_STACK); 
load_idt(&idt_descr); 





from the arch/x86/kernel/traps.c. We already saw implementation of the set_intr_gate_ist 
and set_system_intr_gate_ist functions in the previous part and now we will look on the 





implementation of these two exceptions handlers. 


Debug and Breakpoint exceptions 


Ok, we setup exception handlers in the early_trap_init function for the #pB and #BP 
exceptions and now time is to consider their implementations. But before we will do this, first 
of all let's look on details of these exceptions. 


The first exceptions - #DB Or debug exception occurs when a debug event occurs. For 
example - attempt to change the contents of a debug register. Debug registers are special 
registers that were presented in x86 processors starting from the Intel 80386 processor 
and as you can understand from name of this CPU extension, main purpose of these 
registers is debugging. 


These registers allow to set breakpoints on the code and read or write data to trace it. 
Debug registers may be accessed only in the privileged mode and an attempt to read or 
write the debug registers when executing at any other privilege level causes a general 
protection fault exception. That's why we have used set_intr_gate_ist forthe #pB 
exception, but not the set_system_intr_gate_ist . 





The verctor number of the #pB exceptions is 1 (we pass itas x86_TRAP_DB ) and as we 
may read in specification, this exception has no error code: 


EE + 
| Vector |Mnemonic |Description |Type |Error Code| 
(6 SS pee SSS Sap SeSers Sse SSGes sees See S en Seon Sas sesSssass + 
|1 | #DB |Reserved |F/T |NO | 
本 十 


The second exception is #BP Or breakpoint exception occurs when processor executes 
the int 3 instruction. Unlike the pe exception, the #ep exception may occur in userspace. 
We can add it anywhere in our code, for example let's look on the simple program: 


/ 


#include <stdio.h> 


int main() { 
int i; 
while (i < 6){ 
printi i equal tor Nn i); 
__asm__("int3"); 


++i; 


If we will compile and run this program, we will see following output: 


$ gcc breakpoint.c -o breakpoint 
i equal to: 0 
Trace/breakpoint trap 


But if will run it with gdb, we will see our breakpoint and can continue execution of our 
program: 


$ gdb breakpoint 


(gdb) run 
Starting program: /home/alex/breakpoints 
i equal to: 0 


Program received signal SIGTRAP, Trace/breakpoint trap. 

0x0000000000400585 in main () 

=> 0x0000000000400585 <main+31>: 83 45 fc 01 add DWORD PTR [rbp-0x4], 0x1 
(gdb) c 

Continuing. 

i equal to: 1 


Program received signal SIGTRAP, Trace/breakpoint trap. 

0x0000000000400585 in main () 

=> 0x0000000000400585 <main+31>: 83 45 fc 01 add DWORD PTR [rbp-0x4], 0x1 
(gdb) c 

Continuing. 

i equal to: 2 


Program received signal SIGTRAP, Trace/breakpoint trap. 


0x0000000000400585 in main () 
=> 0x0000000000400585 <maint+31>: 83 45 fc 01 add DWORD PTR [rbp-0x4], 0x1 


From this moment we know a little about these two exceptions and we can move on to 
consideration of their handlers. 


Preparation before an exception handler 





As you may note before, the set_intr_gate_ist and set_system_intr_gate_ist functions 
takes an addresses of exceptions handlers in theirs second parameter. In or case our two 
exception handlers will be: 


e debug ; 


© int3. 


You will not find these functions in the C code. all of that could be found in the kernel's 
*.c/*.h files only definition of these functions which are located in the 
arch/x86/include/asm/traps.h kernel header file: 


asmlinkage void debug(void); 


and 


asmlinkage void int3(void); 


You may note asmlinkage directive in definitions of these functions. The directive is the 
special specificator of the gcc. Actually fora c functions which are called from assembly, 
we need in explicit declaration of the function calling convention. In our case, if function 
made with asmlinkage descriptor, then gcc will compile the function to retrieve parameters 
from stack. 


So, both handlers are defined in the arch/x86/entry/entry_64.S assembly source code file 
with the idtentry macro: 


idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK 


and 


idtentry int3 do_int3 has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK 


Each exception handler may be consists from two parts. The first part is generic part and it is 
the same for all exception handlers. An exception handler should to save general! purpose 
registers on the stack, switch to kernel stack if an exception came from userspace and 
transfer control to the second part of an exception handler. The second part of an exception 
handler does certain work depends on certain exception. For example page fault exception 
handler should find virtual page for given address, invalid opcode exception handler should 
send SIGILL signal and etc. 


As we just saw, an exception handler starts from definition of the idtentry macro from the 
arch/x86/kernel/entry_64.S assembly source code file, so let's look at implementation of this 
macro. As we may see, the idtentry macro takes five arguments: 


e sym - defines global symbol with the .globl name which will be an an entry of 
exception handler; 

e do_sym - symbol name which represents a secondary entry of an exception handler; 

e has_error_code - information about existence of an error code of exception. 


The last two parameters are optional: 


e paranoid - shows us how we need to check current mode (will see explanation in 
details later); 
e shift_ist - shows us is an exception running at Interrupt Stack Table . 


Definition of the .idtentry macro looks: 


.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 
ENTRY(\sym) 


END(\sym) 
.endm 


Before we will consider internals of the idtentry macro, we should to know state of stack 
when an exception occurs. As we may read in the Intel® 64 and IA-32 Architectures 
Software Developer’s Manual 3A, the state of stack when an exception occurs is following: 


ee + 
+40 | %SS | 
+32 | %RSP | 
+24 | %RFLAGS | 
+16 | %CS | 
+8 | %RIP | 
© | ERROR CODE | <-- %RSP 


Now we may start to consider implementation of the idtmacro . Both #pB and BP 
exception handlers are defined as: 


idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK 
idtentry int3 do_int3 has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK 


If we will look at these definitions, we may know that compiler will generate two routines with 
debug and int3 names and both of these exception handlers will call do_debug and 
do_int3 secondary handlers after some preparation. The third parameter defines existence 

of error code and as we may see both our exception do not have them. As we may see on 

the diagram above, processor pushes error code on stack if an exception provides it. In our 
case, the debug and int3 exception do not have error codes. This may bring some 
difficulties because stack will look differently for exceptions which provides error code and 
for exceptions which not. That's why implementation of the idtentry macro starts from 
putting a fake error code to the stack if an exception does not provide it: 


.ifeq \has_error_code 
pushq $-1 
.endif 


But it is not only fake error-code. Moreover the -1 also represents invalid system call 
number, so that the system call restart logic will not be triggered. 


The last two parameters of the idtentry macro shift_ist and paranoid allow to know do 
an exception handler runned at stack from Interrupt Stack Table or not. You already may 
know that each kernel thread in the system has own stack. In addition to these stacks, there 
are some specialized stacks associated with each processor in the system. One of these 
stacks is - exception stack. The x86_64 architecture provides special feature which is called 
- Interrupt Stack Table . This feature allows to switch to a new stack for designated events 
such as an atomic exceptions like double fault and etc. So the shift_ist parameter 
allows us to know do we need to switch on ist stack for an exception handler or not. 


The second parameter - paranoid defines the method which helps us to know did we come 
from userspace or not to an exception handler. The easiest way to determine this is to via 

CPL OF Current Privilege Level in cs segment register. If itis equal to 3 ,we came from 
userspace, if zero we came from kernel space: 


testl $3,CS(%rsp) 
jnz userspace 


// we are from the kernel space 


But unfortunately this method does not give a 100% guarantee. As described in the kernel 
documentation: 


if we are in an NMI/MCE/DEBUG/whatever super-atomic entry context, which might 
have triggered right after a normal entry wrote CS to the stack but before we executed 
SWAPGS, then the only safe way to check for GS is the slower method: the RDMSR. 


In other words for example NMI could happen inside the critical section of a swapgs 
instruction. In this way we should check value of the msr_cs_sase model specific register 
which stores pointer to the start of per-cpu area. So to check did we come from userspace or 
not, we should to check value of the msr_cs_BasE model specific register and if it is negative 
we came from kernel space, in other way we came from userspace: 


movl $MSR_GS_BASE, %ecx 
rdmsr 

testl %edx, %edx 

js if 


In first two lines of code we read value of the msr 6s BASE model specific register into 
edx:eax pair. We can't set negative value to the gs from userspace. But from other side 

we know that direct mapping of the physical memory starts from the oxffff880000000000 

virtual address. In this way, msr_cs_ BASE will contain an address from 6xffff880000000000 


to oxffffc7ffffffffff . After the rdmsr instruction will be executed, the smallest possible 
value in the %edx register willbe - oxffff8800 whichis -30720 in unsigned 4 bytes. That's 
why kernel space gs which points to start of per-cpu area will contain negative value. 


After we pushed fake error code on the stack, we should allocate space for general purpose 
registers with: 


ALLOC_PT_GPREGS_ON_STACK 





macro which is defined in the arch/x86/entry/calling.h header file. This macro just allocates 
15*8 bytes space on the stack to preserve general purpose registers: 


.macro ALLOC_PT_GPREGS_ON_STACK addskip=0 
addq $-(15*8+\addskip), %rsp 
.endm 





So the stack will look like this after execution of the ALLoc PT_GPREGS ON_STACK : 





%RFLAGS 
%CS 

%RIP 

ERROR CODE 


<- %RSP 


After we allocated space for general purpose registers, we do some checks to understand 
did an exception come from userspace or not and if yes, we should move back to an 
interrupted process stack or stay on exception stack: 


.if \paranoid 
.if \paranoid == 
testb $3, CS(%rsp) 
jnz 1f 
.endif 
call paranoid_entry 
.else 
call error_entry 
.endif 


Let's consider all of these there cases in course. 


An exception occured in userspace 


In the first let's consider a case when an exception has paranoid=1 like our debug and 
int3 exceptions. In this case we check selector from cs segment register and jump at 
1f label if we came from userspace or the paranoid_entry will be called in other way. 


Let's consider first case when we came from userspace to an exception handler. As 
described above we should jump at 1 label. The 1 label starts from the call of the 


call error_entry 


routine which saves all general purpose registers in the previously allocated area on the 
stack: 


SAVE_C_REGS 8 
SAVE_EXTRA_REGS 8 


These both macros are defined in the arch/x86/entry/calling.h header file and just move 
values of general purpose registers to a certain place at the stack, for example: 


.macro SAVE_EXTRA_REGS offset=0 
movg %r15, 0*8+\offset(%rsp) 
movg %r14, 1*8+\offset(%rsp) 
movg %r13, 2*8+\offset(%rsp) 
movg %r12, 3*8+\offset(%rsp) 
movg %rbp, 4*8+\offset(%rsp) 
movg %rbx, 5*8+\offset(%rsp) 

,endm 


After execution of SAvE_C_REGS and SAVE_EXTRA_REGS the stack will look: 


%RFLAGS 
%CS 

%RIP 

ERROR CODE 


<- %RSP 


After the kernel saved general purpose registers at the stack, we should check that we came 
from userspace space again with: 


testb $3, CS+8(%rsp) 
jz .Lerror_kernelspace 


because we may have potentially fault if as described in documentation truncated %RIP 
was reported. Anyway, in both cases the SWAPGS instruction will be executed and values 
from MSR_KERNEL_GS_BASE and msr_Gs_BASE will be swapped. From this moment the %gs 
register will point to the base address of kernel structures. So, the swapcs instruction is 
called and it was main point of the error_entry routing. 


Now we can back to the idtentry macro. We may see following assembler code after the 


call of error_entry : 


movq %rsp, %rdi 
call sync_regs 


Here we put base address of stack pointer %rdi register which will be first argument 
(according to x86_64 ABI) of the sync_regs function and call this function which is defined 
in the arch/x86/kernel/traps.c source code file: 


asmlinkage _ visible notrace struct pt_regs *sync_regs(struct pt_regs *eregs) 
{ 

struct pt_regs *regs = task_pt_regs(current); 

*regs = *eregs; 

return regs; 


This function takes the result of the task_ptr_regs macro which is defined in the 
arch/x86/include/asm/processor.h header file, stores it in the stack pointer and return it. The 
task_ptr_regs macro expands to the address of thread.spo which represents pointer to 

the normal kernel stack: 


#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.spO - 1) 


As we came from userspace, this means that exception handler will run in real process 
context. After we got stack pointer from the sync_regs we switch stack: 


movq %rax, %rsp 


The last two steps before an exception handler will call secondary handler are: 


1. Passing pointer to pt_regs structure which contains preserved general purpose 
registers to the %rdi register: 


movq %rsp, %rdi 


as it will be passed as first parameter of secondary exception handler. 


1. Pass error code to the %rsi register as it will be second argument of an exception 
handler and set it to -1 on the stack for the same purpose as we did it before - to 
prevent restart of a system call: 


.if \has_error_code 
movq ORIG_RAX(%rsp), %rsi 
movq $-1, ORIG_RAX(%rsp) 
„else 
xorl %esi, %esi 
.endif 


Additionally you may see that we zeroed the %esi register above in a case if an exception 
does not provide error code. 


In the end we just call secondary exception handler: 


call \do_sym 


which: 


dotraplinkage void d ebug(struct pt_regs *regs, long error_code); 


will be for debug exception and: 


dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code); 


will be for int 3 exception. In this part we will not see implementations of secondary 
handlers, because of they are very specific, but will see some of them in one of next parts. 


We just considered first case when an exception occurred in userspace. Let's consider last 
two. 


An exception with paranoid > 0 occurred in 
kernelspace 


In this case an exception was occurred in kernelspace and idtentry macro is defined with 

paranoid=1 for this exception. This value of paranoid means that we should use slower 
way that we saw in the beginning of this part to check do we really came from kernelspace 
or not. The paranoid_entry routing allows us to know this: 


ENTRY(paranoid_entry) 
cld 
SAVE_C_REGS 8 
SAVE_EXTRA_REGS 8 
movl $1, %ebx 
movl $MSR_GS_BASE, %ecx 


rdmsr 

testl %edx, %edx 

js 1f 

SWAPGS 

xorl %ebx, %ebx 
aby ret 


END(paranoid_entry) 


As you may see, this function represents the same that we covered before. We use second 
(slow) method to get information about previous state of an interrupted task. As we checked 
this and executed swapes in a case if we came from userspace, we should to do the same 


that we did before: We need to put pointer to a structure which holds general purpose 
registers to the %rdi (which will be first parameter of a secondary handler) and put error 
code if an exception provides it to the %rsi (which will be second parameter of a secondary 
handler): 


movq %rsp, %rdi 


.if \has_error_code 
movq ORIG_RAX(%rsp), %rsi 
movq $-1, ORIG_RAX(%rsp) 
.else 
xorl %esi, %esi 
.endif 


The last step before a secondary handler of an exception will be called is cleanup of new 
Ist stack fram: 


.if \shift_ist != -1 
subq $EXCEPTION_STKSZ, CPU_TSS_IST(\shift_ist) 
endif 


You may remember that we passed the shift_ist as argument ofthe idtentry macro. 
Here we check its value and if its not equal to -1 , we get pointer to a stack from Interrupt 
Stack Table by shift_ist index and setup it. 


In the end of this second way we just call secondary exception handler as we did it before: 


call \do_sym 


The last method is similar to previous both, but an exception occured with paranoid=0 and 
we may use fast method determination of where we are from. 


Exit from an exception handler 


After secondary handler will finish its works, we will return to the idtentry macro and the 
next step will be jump to the error_exit : 


jmp error_exit 


routine. The error_exit function defined in the same arch/x86/entry/entry_64.S assembly 
source code file and the main goal of this function is to know where we are from (from 
userspace or kernelspace) and execute sweacs depends on this. Restore registers to 


previous state and execute iret instruction to transfer control to an interrupted task. 


That's all. 


Conclusion 


It is the end of the third part about interrupts and interrupt handling in the Linux kernel. We 
saw the initialization of the Interrupt descriptor table in the previous part with the #pB and 
#BP gates and started to dive into preparation before control will be transferred to an 
exception handler and implementation of some interrupt handlers in this part. In the next part 
we will continue to dive into this theme and will go next by the setup_arch function and will 
try to understand interrupts handling related stuff. 


If you have any questions or suggestions write me a comment or ping me at twitter. 


Please note that English is not my first language, And | am really sorry for any 
inconvenience. If you find any mistakes please send me PR to linux-insides. 
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Interrupts and Interrupt Handling. Part 4. 


Initialization of non-early interrupt gates 


This is fourth part about an interrupts and exceptions handling in the Linux kernel and in the 
previous part we saw first early #pB and #BP exceptions handlers from the 
arch/x86/kernel/traps.c. We stopped on the right after the early_trap_init function that 
called in the setup_arch function which defined in the arch/x86/kernel/setup.c. In this part 
we will continue to dive into an interrupts and exceptions handling in the Linux kernel for 

x86_64 and continue to do it from the place where we left off in the last part. First thing 
which is related to the interrupts and exceptions handling is the setup of the #PF or page 
fault handler with the early_trap_pf_init function. Let's start from it. 


Early page fault handler 


The early_trap_pf_init function defined in the arch/x86/kernel/traps.c. It uses 
set_intr_gate macro that fills Interrupt Descriptor Table with the given entry: 


void __init early rap_r init (void) 
{ 
#ifdef CONFIG_X86_64 
set_intr_gate(X86_TRAP_PF, page_fault); 
#endif 
} 


This macro defined in the arch/x86/include/asm/desc.h. We already saw macros like this in 
the previous part- set_system_intr_gate and set_intr_gate_ist . This macro checks that 
given vector number is not greater than 255 (maximum vector number) and calls 


_set_gate function aS set_system_intr_gate and set_intr_gate_ist did it: 


#define set_intr_gate(n, addr) \ 
do { \ 
BUG_ON((unsigned)n > OxFF); N 
_set_gate(n, GATE_INTERRUPT, (void *)addr, 0, 0, \ 
__KERNEL_CS); N 
_trace_set_gate(n, GATE_INTERRUPT, (void *)trace_##addr,\ 
0, ©, __KERNEL_CS); N 

} while (0) 


The set_intr_gate macro takes two parameters: 


e vector number of a interrupt; 
e address of an interrupt handler; 


In our case they are: 


@ X86_TRAP_PF - 14 


e page_fault - the interrupt handler entry point. 


The xs6_TRAP_PF is the element of enum which defined in the 
arch/x86/include/asm/traprs.h: 


enum { 


X86_TRAP_PF, /* 14, Page Fault */ 


When the early_trap_pf_init will be called, the set_intr_gate will be expanded to the call 
of the _set_gate which will fill the ror with the handler for the page fault. Now let's look on 
the implementation of the page fault handler. The page fault handler defined in the 
arch/x86/kernel/entry_64.S assembly source code file as all exceptions handlers. Let's look 
on it: 


trace_idtentry page_fault do_page_fault has_error_code=1 


We saw in the previous part how #pB and #ep handlers defined. They were defined with 
the idtentry macro, but here we can see trace_idtentry . This macro defined in the same 
source code file and depends on the coNFIG_TRACING kernel configuration option: 


#ifdef CONFIG_TRACING 

.macro trace_idtentry sym do_sym has_error_code:req 

idtentry trace(\sym) trace(\do_sym) has_error_code=\has_error_code 
idtentry \sym \do_sym has_error_code=\has_error_code 

,endm 

#else 

.macro trace_idtentry sym do_sym has_error_code:req 

idtentry \sym \do_sym has_error_code=\has_error_code 

.endm 

#endif 


We will not dive into exceptions Tracing now. If coNFIG_TRACING is not set, we can see that 
trace_idtentry macro just expands to the normal idtentry . We already saw 

implementation of the idtentry macro in the previous part, so let's start from the 
page_fault exception handler. 


As we can see inthe idtentry definition, the handler of the page_fault iS do_page_fault 
function which defined in the arch/x86/mm/fault.c and as all exceptions handlers it takes two 
arguments: 


e regs - pt_regs structure that holds state of an interrupted process; 
e error_code - error code of the page fault exception. 


Let's look inside this function. First of all we read content of the cr2 control register: 


dotraplinkage void notrace 
do_page_fault(struct pt_regs *regs, unsigned long error_code) 
{ 


unsigned long address = read cr2(); 


This register contains a linear address which caused page fault . In the next step we make 
a call of the exception_enter function from the include/linux/context_tracking.h. The 

exception_enter and exception_exit are functions from context tracking subsystem in the 
Linux kernel used by the RCU to remove its dependency on the timer tick while a processor 
runs in userspace. Almost in the every exception handler we will see similar code: 


enum ctx_state prev_state,; 
prev_state = exception_enter(); 


exception_exit(prev_state); 


The exception_enter function checks that context tracking is enabled with the 
context_tracking_is_enabled and if itis in enabled state, we get previous context with the 
this_cpu_read (more about this_cpu_* operations you can read in the Documentation). 

After this it calls context_tracking_user_exit function which informs the context tracking that 

the processor is exiting userspace mode and entering the kernel: 


static inline enum ctx_state exception_enter(void) 


enum ctx_state prev_ctx; 


if (!context_tracking_is_enabled()) 
return, 0; 


prev_ctx = this_cpu_read(context_tracking.state); 
context_tracking_user_exit(); 


return prev_ctx; 


The state can be one of the: 


enum ctx_state { 
IN_KERNEL = 0, 
IN_USER, 

} state; 


And in the end we return previous context. Between the exception_enter and 
exception_exit we Call actual page fault handler: 


__do_page_fault(regs, error_code, address); 


The _ do page fault is defined in the same source code file as do page fault - 
arch/x86/mm/fault.c. In the beginning of the _ do page fault we check state of the 
kmemcheck checker. The kmemcheck detects warns about some uses of uninitialized 
memory. We need to check it because page fault can be caused by kmemcheck: 


if (kmemcheck_active(regs) ) 
kmemcheck_hide(regs); 
prefetchw(&mm->mmap_sem); 


After this we can see the call of the prefetchw which executes instruction with the same 
name which fetches X86 FEATURE_3DNOW to get exclusive cache line. The main purpose 
of prefetching is to hide the latency of a memory access. In the next step we check that we 
got page fault not in the kernel space with the following condition: 


if (unlikely(fault_in_kernel_space(address))) { 


Where fault_in_kernel_space is: 


static int fault_in_kernel_space(unsigned long address) 


{ 
return address >= TASK_SIZE_MAX; 


The TASK_SIZE_MAX macro expands to the: 


#define TASK_SIZE_MAX  ((1UL << 47) - PAGE_SIZE) 


or ox00007ffffffffooo . Pay attention on unlikely macro. There are two macros in the 


Linux kernel: 
#define likely(x) __builtin_expect(!!(x), 1) 
#define unlikely(x) __builtin_expect(!!(x), 0) 


You can often find these macros in the code of the Linux kernel. Main purpose of these 
macros is optimization. Sometimes this situation is that we need to check the condition of 
the code and we know that it will rarely be true or false . With these macros we can tell 
to the compiler about this. For example 


static int proc_root_readdir(struct file *file, struct dir_context *ctx) 


{ 
if (ctx->pos < FIRST_PROCESS_ENTRY) { 


int error = proc_readdir(file, ctx); 
if (unlikely(error <= 0)) 
return error; 


Here we can see proc_root_readdir function which will be called when the Linux VFS 
needs to read the root directory contents. If condition marked with unlikely , compiler 
can put false code right after branching. Now let's back to the our address check. 
Comparison between the given address and the oxoooe7ffffffffeee will give us to know, 
was page fault in the kernel mode or user mode. After this check we know it. After this 
__do_page_fault routine will try to understand the problem that provoked page fault 
exception and then will pass address to the appropriate routine. It can be kmemcheck fault, 
spurious fault, kprobes fault and etc. Will not dive into implementation details of the page 


fault exception handler in this part, because we need to know many different concepts which 
are provided by the Linux kernel, but will see it in the chapter about the memory 
management in the Linux kernel. 


Back to start_kernel 


There are many different function calls after the early_trap_pf_init inthe setup_arch 
function from different kernel subsystems, but there are no one interrupts and exceptions 
handling related. So, we have to go back where we came from -  start_kernel function from 
the init/main.c. The first things after the setup_arch isthe trap_init function from the 
arch/x86/kernel/traps.c. This function makes initialization of the remaining exceptions 
handlers (remember that we already setup 3 handlers for the #pB - debug exception, #BP 

- breakpoint exception and #PF - page fault exception). The trap_init function starts from 
the check of the Extended Industry Standard Architecture: 


#ifdef CONFIG_EISA 
void __iomem *p = early_ioremap(QxOFFFD9, 4); 


if (readl(p) == 'E' + ('I'<<8) + ('S'<<16) + ('A'<<24)) 
EISA_bus = 1; 
early_iounmap(p, 4); 
#endif 


Note that it depends on the conric_ersa kernel configuration parameter which represents 

EISA support. Here we use early_ioremap function to map 1/0 memory on the page 
tables. We use readl function to read first 4 bytes from the mapped region and if they are 
equal to ersa string we set EISA_bus to one. In the end we just unmap previously mapped 
region. More about early_ioremap you can read in the part which describes Fix-Mapped 
Addresses and ioremap. 


After this we start to fill the Interrupt Descriptor Table with the different interrupt gates. 


First of all we set #DE Or Divide Error and #NMI OF Non-maskable Interrupt : 


set_intr_gate(X86_TRAP_DE, divide_error); 
set_intr_gate_ist(X86_TRAP_NMI, &nmi, NMI_STACK); 


We use set_intr_gate macro to set the interrupt gate for the #p—E exception and 

set_intr_gate_ist forthe #nmz . You can remember that we already used these macros 
when we have set the interrupts gates for the page fault handler, debug handler and etc, you 
can find explanation of it in the previous part. After this we setup exception gates for the 
following exceptions: 


set_system_intr_gate(X86_TRAP_OF, &overflow); 
set_intr_gate(X86_TRAP_BR, bounds); 
set_intr_gate(X86_TRAP_UD, invalid_op); 
set_intr_gate(X86_TRAP_NM, device_not_available); 


Here we can see: 


e #0F OF Overflow exception. This exception indicates that an overflow trap occurred 
when an special INTO instruction was executed; 

e #BR Or BOUND Range exceeded exception. This exception indicates that a BouND-range- 
exceed fault occurred when a BOUND instruction was executed; 

e #UD OF Invalid opcode exception. Occurs when a processor attempted to execute 
invalid or reserved opcode, processor attempted to execute instruction with invalid 
operand(s) and etc; 

e #NM Or Device Not Available exception. Occurs when the processor tries to execute 

x87 FPU floating point instruction while em flag in the control register cro was set. 


In the next step we set the interrupt gate forthe #DF or Double fault exception: 


set_intr_gate_ist(X86_TRAP_DF, &double_fault, DOUBLEFAULT_STACK); 


This exception occurs when processor detected a second exception while calling an 
exception handler for a prior exception. In usual way when the processor detects another 
exception while trying to call an exception handler, the two exceptions can be handled 
serially. If the processor cannot handle them serially, it signals the double-fault or #DF 
exception. 


The following set of the interrupt gates is: 


set_intr_gate(X86_TRAP_OLD_MF, &coprocessor_segment_overrun) ; 
set_intr_gate(X86_TRAP_TS, &invalid_TSS); 
set_intr_gate(X86_TRAP_NP, &segment_not_present); 
set_intr_gate_ist(X86_TRAP_SS, &stack_segment, STACKFAULT_STACK); 
set_intr_gate(X86_TRAP_GP, &general_protection); 
set_intr_gate(X86_TRAP_SPURIOUS, &spurious_interrupt_bug); 
set_intr_gate(X86_TRAP_MF, &coprocessor_error); 
set_intr_gate(X86_TRAP_AC, &alignment_check); 


Here we can see setup for the following exception handlers: 


e #CSO OF Coprocessor Segment Overrun -this exception indicates that math coprocessor 
of an old processor detected a page or segment violation. Modern processors do not 
generate this exception 

e #TS OF Invalid TSS exception - indicates that there was an error related to the Task 


State Segment. 

e #NP Or Segment Not Present exception indicates that the present flag of a segment 
or gate descriptor is clear during attempt to load one of cs , ds, es, fs ,Or gs 
register. 

e #SS Or Stack Fault exception indicates one of the stack related conditions was 
detected, for example a not-present stack segment is detected when attempting to load 
the ss register. 

e #GP Or General Protection exception indicates that the processor detected one of a 
class of protection violations called general-protection violations. There are many 
different conditions that can cause general-protection exception. For example loading 
the ss, ds, es, fs ,Or gs register with a segment selector for a system segment, 
writing to a code segment or a read-only data segment, referencing an entry in the 

Interrupt Descriptor Table (following an interrupt or exception) that is not an interrupt, 
trap, or task gate and many many more. 

è Spurious Interrupt - a hardware interrupt that is unwanted. 

© #MF Or x87 FPU Floating-Point Error exception caused when the x87 FPU has 
detected a floating point error. 

e #AC Or Alignment Check exception Indicates that the processor detected an unaligned 
memory operand when alignment checking was enabled. 


After that we setup this exception gates, we can see setup of the Machine-check exception: 


#ifdef CONFIG_X86_MCE 
set_intr_gate_ist(X86_TRAP_MC, &machine_check, MCE_STACK); 
#endif 


Note that it depends on the coNFIG_x86_MCE kernel configuration option and indicates that 
the processor detected an internal machine error or a bus error, or that an external agent 
detected a bus error. The next exception gate is for the SIMD Floating-Point exception: 


set_intr_gate(X86_TRAP_XF, &simd_coprocessor_error); 


which indicates the processor has detected an sse or sse2 or sse3 SIMD floating-point 
exception. There are six classes of numeric exception conditions that can occur while 
executing an SIMD floating-point instruction: 


e Invalid operation 
e Divide-by-zero 

e Denormal operand 
e Numeric overflow 
e Numeric underflow 


e Inexact result (Precision) 


In the next step we fill the used_vectors array which defined in the 
arch/x86/include/asm/desc.h header file and represents bitmap : 


DECLARE_BITMAP(used_vectors, NR_VECTORS); 


of the first 32 interrupts (more about bitmaps in the Linux kernel you can read in the part 
which describes cpumasks and bitmaps) 


for (i = 0; i < FIRST_EXTERNAL_VECTOR; i++) 
set_bit(i, used_vectors) 


where FIRST_EXTERNAL_VECTOR IS: 


#define FIRST_EXTERNAL_VECTOR 0x20 


After this we setup the interrupt gate for the ia32_syscall and add oxso tothe 
used_vectors bitmap: 


#ifdef CONFIG_IA32_EMULATION 
set_system_intr_gate(IA32_SYSCALL_VECTOR, ia32_syscall); 
set_bit(IA32_SYSCALL_VECTOR, used_vectors); 

#endif 


There is CONFIG_IA32_EMULATION kernel configuration option on xs6_64 Linux kernels. This 
option provides ability to execute 32-bit processes in compatibility-mode. In the next parts 
we will see how it works, in the meantime we need only to know that there is yet another 
interrupt gate in the rpt with the vector number oxse . In the next step we maps IDT to 
the fixmap area: 


__set_fixmap(FIX_RO_IDT, pa_symbol(idt_table), PAGE_KERNEL_RO); 
idt_descr.address = fix_to_virt(FIX_RO_IDT); 





and write its address to the idt_descr.address (more about fix-mapped addresses you can 
read in the second part of the Linux kernel memory management chapter). After this we can 
see the call of the cpu_init function that defined in the arch/x86/kernel/cpu/common.c. This 
function makes initialization of the all per-cpu state. In the beginning of the cpu_init we 
do the following things: First of all we wait while current cpu is initialized and than we call the 

cr4_init_shadow function which stores shadow copy of the cr4 control register for the 
current cpu and load CPU microcode if need with the following function calls: 


wait_for_master_cpu(cpu); 
cr4_init_shadow(); 
load_ucode_ap(); 


Next we get the Task state Segment for the current cpu and orig_ist structure which 
represents origin Interrupt Stack Table values with the: 


t = &per_cpu(cpu_tss, cpu); 
Oist = &per_cpu(orig_ist, cpu); 


As we got values of the Task State Segment and Interrupt Stack Table for the current 
processor, we Clear following bits in the cr4 control register: 


cr4_clear_bits(X86_CR4_VME|X86_CR4_PVI|X86_CR4_TSD|X86_CR4_DE); 


with this we disable vmse extension, virtual interrupts, timestamp (RDTSC can only be 
executed with the highest privilege) and debug extension. After this we reload the Global 


Descriptor Table and Interrupt Descriptor table with the: 


switch_to_new_gdt(cpu); 
loadsegment(fs, 0); 
load_current_idt(); 


After this we setup array of the Thread-Local Storage Descriptors, configure NX and load 
CPU microcode. Now is time to setup and load per-cpu Task State Segments. We are 
going in a loop through the all exception stack which is _N_EXCEPTION_STACKS or 4 and fill it 


with Interrupt Stack Tables 


if (!oist->ist[0]) { 
char *estacks = per_cpu(exception_stacks, cpu); 


for (v = O; v < N_EXCEPTION_STACKS; v++) { 
estacks += exception_stack_sizes[v]; 
oist->ist[v] = t->x86_tss.ist[v] = 
(unsigned long)estacks; 
if (v == DEBUG_STACK-1) 
per_cpu(debug_stack_addr, cpu) = (unsigned long)estacks; 


As we have filled Task State Segments with the Interrupt Stack Tables We can set TSS 
descriptor for the current processor and load it with the: 


set_tss_desc(cpu, t); 
load_TR_desc(); 


where set_tss_desc macro from the arch/x86/include/asm/desc.h writes given descriptor to 
the Global Descriptor Table of the given processor: 


#define set_tss_desc(cpu, addr) __set_tss_desc(cpu, GDT_ENTRY_TSS, addr) 
static inline void __set_tss_desc(unsigned cpu, unsigned int entry, void *addr) 
{ 
struct desc_struct *d = get_cpu_gdt_table(cpu); 
tss_desc tss; 
set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, 
IO_BITMAP_OFFSET + IO_BITMAP_BYTES + 
sizeof(unsigned long) - 1); 
write_gdt_entry(d, entry, &tss, DESC_TSS); 


and load_TR_desc macro expands to the ltr or Load Task Register instruction: 


#define load_TR_desc() native_load_tr_desc() 
static inline void native_load_tr_desc(void) 


{ 


asm volatile("1tr %wO"::"q" (GDT_ENTRY_TSS*8)); 


In the end of the trap_init function we can see the following code: 


set_intr_gate_ist(X86_TRAP_DB, &debug, DEBUG_STACK); 
set_system_intr_gate_ist(X86_TRAP_BP, &int3, DEBUG_STACK); 





#ifdef CONFIG_X86_64 
memcpy(&nmi_idt_table, &idt_table, IDT_ENTRIES * 16); 
set_nmi_gate(X86_TRAP_DB, &debug); 
set_nmi_gate(X86_TRAP_BP, &int3); 

#endif 


Here we copy idt_table tothe nmi_dit_table and setup exception handlers for the #DB 
Or Debug exception and #BR OF Breakpoint exception . You can remember that we already 
set these interrupt gates in the previous part, so why do we need to setup it again? We 
setup it again because when we initialized it before in the early_trap_init function, the 
Task State Segment was not ready yet, but now it is ready after the call of the cpu_init 
function. 


That's all. Soon we will consider all handlers of these interrupts/exceptions. 


Conclusion 


It is the end of the fourth part about interrupts and interrupt handling in the Linux kernel. We 
saw the initialization of the Task State Segment in this part and initialization of the different 
interrupt handlers as Divide Error , Page Fault exception and etc. You can note that we 
saw just initialization stuff, and will dive into details about handlers for these exceptions. In 
the next part we will start to do it. 


If you have any questions or suggestions write me a comment or ping me at twitter. 


Please note that English is not my first language, And | am really sorry for any 
inconvenience. If you find any mistakes please send me PR to linux-insides. 
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Interrupts and Interrupt Handling. Part 5. 


Implementation of exception handlers 


This is the fifth part about an interrupts and exceptions handling in the Linux kernel and in 
the previous part we stopped on the setting of interrupt gates to the Interrupt descriptor 
Table. We did it in the trap_init function from the arch/x86/kernel/traps.c source code file. 
We saw only setting of these interrupt gates in the previous part and in the current part we 
will see implementation of the exception handlers for these gates. The preparation before an 
exception handler will be executed is in the arch/x86/entry/entry_64.S assembly file and 
occurs in the idtentry macro that defines exceptions entry points: 


idtentry divide_error do_divide_error has_error_c 
ode=0 

idtentry overflow do_overflow has_error_c 
ode=0 

idtentry invalid_op do_invalid_op has_error_c 
ode=0 

idtentry bounds do_bounds has_error_c 
ode=0 

idtentry device_not_available do_device_not_available has_error_c 
ode=0 

idtentry coprocessor_segment_overrun do_coprocessor_segment_overrun has_error_code= 
0 

idtentry invalid_TSS do_invalid_TSS has_error_cod 
e=1 

idtentry segment_not_present do_segment_not_present has_error_cod 
e=1 

idtentry spurious_interrupt_bug do_spurious_interrupt_bug has_error_c 
ode=0 

idtentry coprocessor_error do_coprocessor_error has_error_cod 
e=0 

idtentry alignment_check do_alignment_check has_error_cod 
e=1 

idtentry simd_coprocessor_error do_simd_coprocessor_error has_error_c 
ode=0 


The idtentry macro does following preparation before an actual exception handler 

( do_divide_error forthe divide_error , do_overflow forthe overflow and etc.) will get 
control. In another words the idtentry macro allocates place for the registers (pt_regs 
structure) on the stack, pushes dummy error code for the stack consistency if an 


interrupt/exception has no error code, checks the segment selector in the cs segment 
register and switches depends on the previous state(userspace or kernelspace). After all of 
these preparations it makes a call of an actual interrupt/exception handler: 


,macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 
ENTRY(\sym) 


call \do_sym 


END(\sym) 
.endm 


After an exception handler will finish its work, the idtentry macro restores stack and 
general purpose registers of an interrupted task and executes iret instruction: 


ENTRY(paranoid_exit) 


RESTORE_EXTRA_REGS 
RESTORE_C_REGS 
REMOVE_PT_GPREGS_FROM_STACK 8 
INTERRUPT_RETURN 
END(paranoid_exit) 





where INTERRUPT_RETURN IS: 


#define INTERRUPT_RETURN jmp native_iret 


ENTRY(native_iret) 

.global native_irgq_return_iret 
native_irq_return_iret: 

iretq 


More about the idtentry macro you can read in the third part of the 
http://Oxax.gitbooks.io/linux-insides/content/interrupts/interrupts-3.html chapter. Ok, now we 
saw the preparation before an exception handler will be executed and now time to look on 
the handlers. First of all let's look on the following handlers: 


e divide_error 
e overflow 
e invalid_op 


e coprocessor_segment_overrun 


e invalid_TSS 


e segment_not_present 


e stack_segment 
e alignment_check 


All these handlers defined in the arch/x86/kernel/traps.c source code file with the po_ERROR 


macro: 


DO_ERROR(X86_TRAP_DE, 
DO_ERROR(X86_TRAP_OF, 
DO_ERROR(X86_TRAP_UD, 


DO_ERROR(X86_TRAP_OLD_MF, 


overrun) 

DO_ERROR( X86_TRAP_TS, 
DO_ERROR( X86_TRAP_NP, 
DO_ERROR( X86_TRAP_SS, 
DO_ERROR( X86_TRAP_AC, 


SIGFPE, 
SIGSEGV, 
SIGILL, 
SIGFPE, 


SIGSEGV, 
SIGBUS, 
SIGBUS, 
SIGBUS, 


"divide error", 
"overflow", 
"invalid opcode", 


"coprocessor segment overrun", 


nv a USS, 
"segment not present", 
"stack segment", 
"alignment check", 


As we can see the po ERROR macro takes 4 parameters: 


e Vector number of an interrupt; 


e Signal number which will be sent to the interrupted process; 


e String which describes an exception; 


e Exception handler entry point. 


divide_error) 
overflow) 
invalid_op) 
coprocessor_segment_ 


invalid_TSS) 
segment_not_present) 
stack_segment ) 
alignment_check) 


This macro defined in the same source code file and expands to the function with the 


do_handler name: 


#define DO_ERROR(trapnr, signr, 
dotraplinkage void do_##name(struct pt_regs *regs, long error_code) 


{ 


do_error_trap(regs, error_code, str, trapnr, signr); 


str, name) 


CO ee ee 


Note onthe ## tokens. This is special feature - GCC macro Concatenation which 


concatenates two given strings. For example, first Do_ERROR in our example will expands to 


the: 


dotraplinkage void do_divide_error(struct pt_regs *regs, long error_code) \ 


{ 


We can see that all functions which are generated by the po_ERROR macro just make a call 
of the do_error_trap function from the arch/x86/kernel/traps.c. Let's look on implementation 
of the do_error_trap function. 


Trap handlers 


The do_error_trap function starts and ends from the two following functions: 


enum ctx_state prev_state = exception_enter(); 


exception_exit(prev_state); 


from the include/linux/context_tracking.h. The context tracking in the Linux kernel subsystem 
which provide kernel boundaries probes to keep track of the transitions between level 
contexts with two basic initial contexts: user or kernel . The exception_enter function 
checks that context tracking is enabled. After this if it is enabled, the exception_enter reads 
previous context and compares it with the conTEXT_KERNEL . If the previous context is user , 
we Call context_tracking_exit function from the kernel/context_tracking.c which inform the 
context tracking subsystem that a processor is exiting user mode and entering the kernel 
mode: 


if (!context_tracking_is_enabled() ) 
return 0; 


prev_ctx = this_cpu_read(context_tracking.state); 
if (prev_ctx != CONTEXT_KERNEL) 
context_tracking_exit(prev_ctx); 


return prev_ctx,; 


If previous context is non user , we just return it. The pre_ctx has enum ctx_state type 
which defined in the include/linux/context_tracking_state.h and looks as: 


enum ctx_state { 
CONTEXT_KERNEL = 0, 
CONTEXT_USER, 
CONTEXT_GUEST, 

} state; 


The second function is exception_exit defined in the same include/linux/context_tracking.h 
file and checks that context tracking is enabled and call the contert_tracking_enter function 
if the previous context was user : 


static inline void exception_exit(enum ctx_state prev_ctx) 


{ 


if (context_tracking_is_enabled()) { 
if (prev_ctx != CONTEXT_KERNEL) 
context_tracking_enter(prev_ctx); 


The context_tracking_enter function informs the context tracking subsystem that a 
processor is going to enter to the user mode from the kernel mode. We can see the following 
code between the exception_enter and exception_exit : 


if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) != 
NOTIFY_STOP) { 
conditional_sti(regs); 
do_trap(trapnr, signr, str, regs, error_code, 
fill_trap_info(regs, signr, trapnr, &info)); 


First of all it calls the notify_die function which defined in the kernel/notifier.c. To get 
notified for kernel panic, kernel oops, Non-Maskable Interrupt or other events the caller 
needs to insert itself in the notify_die chain and the notify_die function does it. The 
Linux kernel has special mechanism that allows kernel to ask when something happens and 
this mechanism called notifiers Or notifier chains . This mechanism used for example 
for the usg hotplug events (look on the drivers/usb/core/notify.c), for the memory hotplug 
(look on the include/linux/memory.h, the hotplug_memory_notifier macro and etc...), system 
reboots and etc. A notifier chain is thus a simple, singly-linked list. When a Linux kernel 
subsystem wants to be notified of specific events, it fills out a special notifier_block 
structure and passes it to the notifier_chain_register function. An event can be sent with 
the call of the notifier_call_chain function. First of all the notify_die function fills 
die_args structure with the trap number, trap string, registers and other values: 


struct die_args args = { 


.regs = regs, 
.str = str, 
„err =err, 


.trapnr = trap, 
.Signr = sig, 


and returns the result of the atomic_notifier_call_chain function with the die chain : 


static ATOMIC_NOTIFIER_HEAD(die_chain); 
return atomic_notifier_call_chain(&die_chain, val, &args); 


which just expands to the atomic_notifier_head structure that contains lock and 


notifier_block 


struct atomic_notifier_head { 
spinlock_t lock; 
struct notifier_block _ rcu *head; 


}; 


The atomic_notifier_call_chain function calls each function in a notifier chain in turn and 
returns the value of the last notifier function called. If the notify_die inthe do_error_trap 
does not return NoTIFY_STOP We execute conditional_sti function from the 
arch/x86/kernel/traps.c that checks the value of the interrupt flag and enables interrupt 
depends on it: 


static inline void conditional_sti(struct pt regs *regs) 
{ 
if (regs->flags & X86_EFLAGS_IF) 
local_irq_enable(); 
} 


more about local irq enable macro you can read in the second part of this chapter. The 
next and last callin the do_error_trap is the do_trap function. First of all the do_trap 

function defined the tsk variable which has task_struct type and represents the current 
interrupted process. After the definition of the tsk , we can see the call of the 
do_trap_no_signal function: 


struct task_struct *tsk = current; 
if (!do_trap_no_signal(tsk, trapnr, str, regs, error_code) ) 
return; 
The do_trap_no_signal function makes two checks: 


e Did we come from the Virtual 8086 mode; 
e Did we come from the kernelspace. 


if (v8086_mode(regs)) { 


if (!user_mode(regs)) { 


return =T; 


We will not consider first case because the long mode does not support the Virtual 8086 
mode. In the second case we invoke fixup_exception function which will try to recover a 
fault and die if we can't: 


if (!fixup_exception(regs)) { 
tsk->thread.error_code = error_code; 
tsk->thread.trap_nr = trapnr; 
die(str, regs, error_code); 


The die function defined in the arch/x86/kernel/dumpstack.c source code file, prints useful 
information about stack, registers, kernel modules and caused kernel oops. If we came from 
the userspace the do_trap_no_signal function will return -1 and the execution of the 

do_trap function will continue. If we passed through the do_trap_no_signal function and 
did not exit from the do_trap after this, it means that previous context was - user . Most 
exceptions caused by the processor are interpreted by Linux as error conditions, for 
example division by zero, invalid opcode and etc. When an exception occurs the Linux 
kernel sends a signal to the interrupted process that caused the exception to notify it of an 
incorrect condition. So, in the do_trap function we need to send a signal with the given 
number ( SIGFPE for the divide error，SIGILL for the overflow exception and etc...). First of 
all we save error code and vector number in the current interrupts process with the filling 


thread.error_code and thread_trap_nr 


tsk->thread.error_code = error_code; 
tsk->thread.trap_nr = trapnr; 


After this we make a check do we need to print information about unhandled signals for the 
interrupted process. We check that show_unhandled_signals variable is set, that 

unhandled_signal function from the kerne!l/signal.c will return unhandled signal(s) and printk 
rate limit: 


#ifdef CONFIG_X86_64 
if (show_unhandled_signals && unhandled_signal(tsk, signr) && 

printk_ratelimit()) { 

pr_info("%s[%d] trap %s ip:%lx sp:%lx error:%1x", 
tsk->comm, tsk->pid, str, 
regs->ip, regs->sp, error_code); 

print_vma_addr(" in", regs->ip); 

pr_cont("\n"); 


} 
#endif 


And send a given signal to interrupted process: 


force_sig_info(signr, info ?: SEND _SIG_PRIV, tsk); 


This is the end of the do_trap . We just saw generic implementation for eight different 
exceptions which are defined with the po_ERROR macro. Now let's look on another exception 
handlers. 


Double fault 


The next exception is #DF Or Double fault . This exception occurs when the processor 
detected a second exception while calling an exception handler for a prior exception. We set 
the trap gate for this exception in the previous part: 


set_intr_gate_ist(X86_TRAP_DF, &double_ fault, DOUBLEFAULT_STACKk) ; 


Note that this exception runs on the bouBLEFAULT_STACK Interrupt Stack Table which has 
index - 1: 


#define DOUBLEFAULT_STACK 1 


The double fault is handler for this exception and defined in the arch/x86/kernel/traps.c. 
The double fault handler starts from the definition of two variables: string that describes 
exception and interrupted process, as other exception handlers: 


static const char str[] = "double fault"; 
struct task_struct *tsk = current; 


The handler of the double fault exception split on two parts. The first part is the check which 
checks that a fault is a_non-IST fault on the espfix64 stack. Actually the iret instruction 
restores only the bottom 16 bits when returning toa 16 bit segment. The espfix feature 
solves this problem. So if the non-IST fault on the espfix64 stack we modify the stack to 
make it look like General Protection Fault 


struct pt_regs *normal_regs = task_pt_regs(current); 
memmove(&normal_regs->ip, (void *)regs->sp, 5*8); 
ormal_regs->orig_ax = 0; 

regs->ip = (unsigned long)general_protection; 


regs->sp = (unsigned long)&normal_regs->orig_ax; 
return; 


In the second case we do almost the same that we did in the previous exception handlers. 
The first is the call of the ist_enter function that discards previous context, user in our 
case: 


ist_enter(regs); 


And after this we fill the interrupted process with the vector number of the Double fault 
exception and error code as we did it in the previous handlers: 


tsk->thread.error_code = error_code; 
tsk->thread.trap_nr = X86_TRAP_DF; 


Next we print useful information about the double fault (PID number, registers content): 


#ifdef CONFIG_DOUBLEFAULT 
df_debug(regs, error_code); 
#endif 


And die: 


for (;;) 
die(str, regs, error_code); 


That's all. 


Device not available exception handler 


The next exception is the #NM Or Device not available . The Device not available 
exception can occur depending on these things: 


e The processor executed an x87 FPU floating-point instruction while the EM flag in 
control register cre was set; 

e The processor executed a wait or fwait instruction while the mp and ts flags of 
register cro were set; 

e The processor executed an x87 FPU, MMX or SSE instruction while the ts flag in 
control register cro was set and the em flag is clear. 


The handler of the Device not available exceptionis the do_device_not_available function 
and it defined in the arch/x86/kernel/traps.c source code file too. It starts and ends from the 
getting of the previous context, as other traps which we saw in the beginning of this part: 


enum ctx_state prev_state,; 
prev_state = exception_enter(); 


exception_exit(prev_state); 


In the next step we check that FPU is not eager: 


BUG_ON(use_eager_fpu()); 





When we switch into a task or interrupt we may avoid loading the Fru state. If a task will 
use it, we catch Device not Available exception exception. If we loading the Fru state 
during task switching, the FPU is eager. In the next step we check cro control register on 
the em flag which can show us is x87 floating point unit present (flag clear) or not (flag 
set): 


#ifdef CONFIG_MATH_EMULATION 
if (read_cr0() & X86_CRO_EM) { 
struct math_emu_info info = { }; 


conditional_sti(regs); 


info.regs = regs; 
math_emulate(&info) ; 
exception_exit(prev_state); 
return; 


} 
#endif 


Ifthe x87 floating point unit not presented, we enable interrupts with the conditional_sti ， 
fill the math_emu_info (defined in the arch/x86/include/asm/math_emu.h) structure with the 
registers of an interrupt task and call math_emulate function from the arch/x86/math- 
emu/fpu_entry.c. As you can understand from function's name, it emulates x87 Feu unit 
(more about the x87 we will know in the special chapter). In other way, if xs6_cre_em flag 
is clear which means that x87 Feu unit is presented, we call the fpu__restore function 
from the arch/x86/kernel/fpu/core.c which copies the Feu registers from the fpustate to 
the live hardware registers. After this Fru instructions can be used: 


fpu__restore(&current->thread.fpu) ; 


General protection fault exception handler 


The next exception is the #GP or General protection fault . This exception occurs when 
the processor detected one of a class of protection violations called general-protection 
violations . It can be: 


e Exceeding the segment limit when accessing the cs , ds, es, fs Or gs Segments; 

e Loading the ss, ds, es, fs or gs register with a segment selector for a system 
segment.; 

e Violating any of the privilege rules; 

e and other... 


The exception handler for this exception is the do_general_protection from the 
arch/x86/kernel/traps.c. The do_general_protection function starts and ends as other 
exception handlers from the getting of the previous context: 


prev_state = exception_enter(); 


exception_exit(prev_state); 


After this we enable interrupts if they were disabled and check that we came from the Virtual 
8086 mode: 


conditional_sti(regs); 


if (v8086_mode(regs)) { 
local_irq_enable(); 
handle_vm86_fault((struct kernel_vm86_regs *) regs, error_code); 


goto exit; 


As long mode does not support this mode, we will not consider exception handling for this 
case. In the next step check that previous mode was kernel mode and try to fix the trap. If 
we can't fix the current general protection fault exception we fill the interrupted process with 
the vector number and error code of the exception and add it to the notify_die chain: 


if (!user_mode(regs)) { 
if (fixup_exception(regs) ) 
goto exit; 


tsk->thread.error_code = error_code; 
tsk->thread.trap_nr = X86_TRAP_GP; 
if (notify_die(DIE_GPF, "general protection fault", regs, error_code, 
X86_TRAP_GP, SIGSEGV) != NOTIFY_STOP) 
die("general protection fault", regs, error_code); 
goto exit; 


If we can fix exception we go to the exit label which exits from exception state: 


exit: 
exception_exit(prev_state); 


If we came from user mode we send SIGsEGv signal to the interrupted process from user 
mode as we did it in the do_trap function: 


if (show_unhandled_signals && unhandled_signal(tsk, SIGSEGV) && 
printk_ratelimit()) { 
pr_info("%s[%d] general protection ip:%lx sp:%lx error:%1x", 
tsk->comm, task_pid_nr (tsk), 
regs->ip, regs->sp, error_code); 
print_vma_addr(" in ", regs->ip); 
pr_cont("\n"); 


force_sig_info(SIGSEGV, SEND_SIG_PRIV, tsk); 


That's all. 


Conclusion 


It is the end of the fifth part of the Interrupts and Interrupt Handling chapter and we saw 
implementation of some interrupt handlers in this part. In the next part we will continue to 
dive into interrupt and exception handlers and will see handler for the Non-Maskable 


Interrupts, handling of the math coprocessor and SIMD coprocessor exceptions and many 
many more. 


If you have any questions or suggestions write me a comment or ping me at twitter. 


Please note that English is not my first language, And | am really sorry for any 
inconvenience. If you find any mistakes please send me PR to linux-insides. 
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Interrupts and Interrupt Handling. Part 6. 


Non-maskable interrupt handler 


It is sixth part of the Interrupts and Interrupt Handling in the Linux kernel chapter and in the 
previous part we saw implementation of some exception handlers for the General Protection 
Fault exception, divide exception, invalid opcode exceptions and etc. As | wrote in the 
previous part we will see implementations of the rest exceptions in this part. We will see 
implementation of the following handlers: 


e Non-Maskable interrupt; 

e BOUND Range Exceeded Exception; 
e Coprocessor exception; 

e SIMD coprocessor exception. 


in this part. So, let's start. 


Non-Maskable interrupt handling 


A Non-Maskable interrupt is a hardware interrupt that cannot be ignored by standard 
masking techniques. In a general way, a non-maskable interrupt can be generated in either 
of two ways: 


e External hardware asserts the non-maskable interrupt pin on the CPU. 
e The processor receives a message on the system bus or the APIC serial bus with a 
delivery mode NMI . 


When the processor receives a NMI from one of these sources, the processor handles it 
immediately by calling the NMI handler pointed to by interrupt vector which has number 2 
(see table in the first part). We already filled the Interrupt Descriptor Table with the vector 
number, address of the nmi interrupt handler and nmz_stack Interrupt Stack Table entry: 


set_intr_gate_ist(X86_TRAP_NMI, &nmi, NMI_STACK); 


in the trap_init function which defined in the arch/x86/kernel/traps.c source code file. In 
the previous parts we saw that entry points of the all interrupt handlers are defined with the: 


,macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 
ENTRY(\sym) 


END(\sym) 
.endm 


macro from the arch/x86/entry/entry_64.S assembly source code file. But the handler of the 
Non-Maskable interrupts is not defined with this macro. It has own entry point: 


ENTRY(nmi) 


END(nmi) 


in the same arch/x86/entry/entry_64.S assembly file. Lets dive into it and will try to 
understand how Non-Maskable interrupt handler works. The nmi handlers starts from the 
call of the: 


PARAVIRT_ADJUST_EXCEPTION_FRAME 


macro but we will not dive into details about it in this part, because this macro related to the 
Paravirtualization stuff which we will see in another chapter. After this save the content of the 
rdx register on the stack: 


pushq %r dx 


And allocated check that cs was not the kernel segment when an non-maskable interrupt 
occurs: 


cmpl $ KERNEL_CS, 16(%rsp) 
jne first_nmi 


The _ KkERNEL cS macro defined in the arch/x86/include/asm/segment.h and represented 
second descriptor in the Global Descriptor Table: 


#define GDT_ENTRY_KERNEL_CS 2 
#define __KERNEL_CS (GDT_ENTRY_KERNEL_CS*8) 








more about cpt you can read in the second part of the Linux kernel booting process 
chapter. If cs is not kernel segment, it means that it is not nested NMI and we jump on the 
first_nmi label. Let's consider this case. First of all we put address of the current stack 
pointer to the rdx and pushes 1 tothe stack inthe first_nmi label: 


first_nmi: 
movq (%rsp), %rdx 
pushq $1 


Why do we push 1 onthe stack? As the comment says: we allow breakpoints in NMIs . 
On the x86 64, like other architectures, the CPU will not execute another nmz until the first 

NMI is completed. A NMI interrupt finished with the iret instruction like other interrupts and 
exceptions do it. If the NMI handler triggers either a page fault or breakpoint or another 
exception which are use iret instruction too. If this happens while in NMI context, the 
CPU will leave NMI context and anew NMI may come in. The iret used to return from 
those exceptions will re-enable NMIs and we will get nested non-maskable interrupts. The 
problem the nmz handler will not return to the state that it was, when the exception 
triggered, but instead it will return to a state that will allow new NMIs to preempt the running 

NMI handler. If another NMI comes in before the first NMI handler is complete, the new 
NMI will write all over the preempted nmis stack. We can have nested NMIs where the 
next NMI is using the top of the stack of the previous NMI . It means that we cannot 
execute it because a nested non-maskable interrupt will corrupt stack of a previous non- 
maskable interrupt. That's why we have allocated space on the stack for temporary variable. 
We will check this variable that it was set when a previous NMI is executing and clear if it is 
not nested NMI . We push 1 here to the previously allocated space on the stack to denote 
that a non-maskable interrupt executed currently. Remember that when and NMI or another 
exception occurs we have the following stack frame: 


acena tanhon oa naoso nan + 
l SS | 
| RSP | 
| RFLAGS | 
| CS | 
| RIP | 
Se otaca a nAn oaae + 


and also an error code if an exception has it. So, after all of these manipulations our stack 
frame will look like this: 


SS 
RSP 
RFLAGS 


a] 
n 


In the next step we allocate yet another 40 bytes on the stack: 


subq $(5*8), %rsp 


and pushes the copy of the original stack frame after the allocated space: 


.rept 5 
pushq 11*8(%rsp) 
.endr 


with the .rept assembly directive. We need in the copy of the original stack frame. Generally 
we need in two copies of the interrupt stack. First is copied interrupts stack: saved stack 
frame and copied stack frame. Now we pushes original stack frame to the saved stack 
frame which locates after the just allocated 40 bytes ( copied stack frame). This stack 
frame is used to fixup the copied stack frame that a nested NMI may change. The second - 

copied stack frame modified by any nested NMIs to let the first NMI know that we 
triggered a second NMI and we should repeat the first NMI handler. Ok, we have made 
first copy of the original stack frame, now time to make second copy: 


addq $(10*8), %rsp 


.rept 5 

pushq -6*8(%rsp) 
.endr 

subq $(5*8), %rsp 


After all of these manipulations our stack frame will be like this: 


| original SS | 
| original Return RSP | 
| original RFLAGS | 
| original CS | 
| original RIP | 


| copied SS | 
| copied Return RSP | 
| copied RFLAGS | 
| copied CS | 
| | 


| Saved SS | 
| Saved Return RSP | 
| Saved RFLAGS | 
| Saved CS | 
| | 


Afterthis we push dummy error code on the stack as we did it already in the previous 
exception handlers and allocate space for the general purpose registers on the stack: 


pushq $-1 
ALLOC_PT_GPREGS_ON_STACK 





We already saw implementation of the ALLoc_PT_GREGS_ON_STACK macro in the third part of 
the interrupts chapter. This macro defined in the arch/x86/entry/calling.h and yet another 
allocates 120 bytes on stack for the general purpose registers, from the rdi tothe r15 : 


.macro ALLOC_PT_GPREGS_ON_STACK addskip=0 
addq $-(15*8+\addskip), %rsp 
.endm 





After space allocation for the general registers we can see call of the paranoid_entry : 


call paranoid_entry 


We can remember from the previous parts this label. It pushes general purpose registers on 
the stack, reads msr_cs_BASE Model Specific register and checks its value. If the value of 
the msr_Gs_BASE is negative, we came from the kernel mode and just return from the 


paranoid_entry , in other way it means that we came from the usermode and need to 
execute swapgs instruction which will change user gs with the kernel gs : 


ENTRY(paranoid_entry) 
cld 
SAVE_C_REGS 8 
SAVE_EXTRA_REGS 8 
movl $1, %ebx 
movl $MSR_GS_BASE, %ecx 


rdmsr 

testl %edx, %edx 

js 1f 

SWAPGS 

xorl %ebx, %ebx 
alig ret 


END(paranoid_entry) 


Note that after the swapgs instruction we zeroed the ebx register. Next time we will check 
content of this register and if we executed swapgs than ebx must contain o and 1 in 
other way. In the next step we store value of the cr2 control register to the r12 register, 
because the NMI handler can cause page fault and corrupt the value of this control 
register: 


movq %cr2, %r12 


Now time to call actual NMI handler. We push the address of the pt_regs tothe rdi, 
error code to the rsi and call the do_nmi handler: 


movq %rsp, %rdi 
movq $-1, %rsi 
call do_nmi 


We will back to the do_nmi little later in this part, but now let's look what occurs after the 
do_nmi Will finish its execution. After the do_nmi handler will be finished we check the cr2 
register, because we can got page fault during do_nmi performed and if we got it we restore 

original cr2 ,in other way we jump on the label 1 . After this we test content of the ebx 
register (remember it must contain o if we have used swapgs instruction and 1 if we 
didn't use it) and execute swAPGS_UNSAFE_STACK if it contains 1 or jump tothe nmi_restore 
label. The swaPpGs_UNSAFE_STACK macro just expands to the swapgs instruction. In the 
nmi_restore label we restore general purpose registers, clear allocated space on the stack 
for this registers, clear our temporary variable and exit from the interrupt handler with the 


INTERRUPT_RETURN macro: 


movq %cr2, %rcx 
cmpq %rcx, %r12 
je 1f 

movq %r12, %cr2 


testl %ebx, %ebx 
jnz nmi_restore 
nmi_swapgs: 
SWAPGS_UNSAFE_STACK 
nmi_restore: 
RESTORE_EXTRA_REGS 
RESTORE_C_REGS 
/* Pop the extra iret frame at once */ 
REMOVE_PT_GPREGS_FROM_STACK 6*8 
/* Clear the NMI executing stack variable */ 
movq $0, 5*8(%rsp) 
INTERRUPT_RETURN 





where INTERRUPT_RETURN is defined in the arch/x86/include/irqflags.h and just expands to the 
iret instruction. That's all. 


Now let's consider case when another NMI interrupt occurred when previous NMI interrupt 
didn't finish its execution. You can remember from the beginning of this part that we've made 
a check that we came from userspace and jump on the first_nmi in this case: 


cmpl $ KERNEL_CS, 16(%rsp) 
jne first_nmi 


Note that in this case it is first NMI every time, because if the first NMI catched page fault, 
breakpoint or another exception it will be executed in the kernel mode. If we didn't come 
from userspace, first of all we test our temporary variable: 


cmpl $1, -8(%rsp) 
je nested_nmi 


and if it is setto 1 we jump to the nested_nmi label. If itis not 1 ,we test the 1st stack. 
In the case of nested NMIs we check that we are above the repeat_nmi . In this case we 
ignore it, in other way we check that we above than end_repeat_nmi and jump on the 


nested_nmi_out label. 


Now let's look on the do_nmi exception handler. This function defined in the 
arch/x86/kernel/nmi.c source code file and takes two parameters: 


e address ofthe pt_regs ; 
e error code. 


as all exception handlers. The do_nmi starts from the call of the nmi_nesting_preprocess 
function and ends with the call of the nmi_nesting_postprocess . The 
nmi_nesting_preprocess function checks that we likely do not work with the debug stack and 
if we on the debug stack set the update_debug_stack per-cpu variable to 1 and call the 
debug_stack_set_zero function from the arch/x86/kernel/cpu/common.c. This function 
increases the debug_stack_use_ctr per-cpu variable and loads new Interrupt Descriptor 


Table : 
static inline void nmi_nesting_preprocess(struct pt_regs *regs) 
{ 

If (unlikely(is_debug_stack(regs->sp))) { 
debug_stack_set_zero(); 
this_cpu_write(update_debug_stack, 1); 

} 

} 


The nmi_nesting_postprocess function checks the update_debug_stack per-cpu variable 
which we setin the nmi_nesting_preprocess and resets debug stack or in another words it 
loads origin Interrupt Descriptor Table . After the call of the nmi_nesting_preprocess 
function, we can see the call of the nmi enter inthe do nmi . The nmi_enter increases 

lockdep_recursion field of the interrupted process, update preempt counter and informs the 
RCU subsystem about NMI . There is also nmi_exit function that does the same stuff as 

nmi_enter , but vice-versa. After the nmi_enter we increase _ nmi count inthe irq_stat 
structure and call the default_do_nmi function. First of all in the default_do_nmi we check 
the address of the previous nmi and update address of the last nmi to the actual: 


if (regs->ip == __this_cpu_read(last_nmi_rip) ) 
b2b = true; 

else 
__this_cpu_write(swallow_nmi, false); 


__this_cpu_write(last_nmi_rip, regs->ip); 


After this first of all we need to handle CPU-specific NMIs : 


handled = nmi_handle(NMI_LOCAL, regs, b2b); 
__this_cpu_add(nmi_stats.normal, handled); 


And then non-specific NMIs depends on its reason: 


reason = x86_platform.get_nmi_reason(); 
if (reason & NMI_REASON_MASK) { 
if (reason & NMI_REASON_SERR) 
pci_serr_error(reason, regs); 
else if (reason & NMI_REASON_IOCHK) 
io_check_error(reason, regs); 


__this_cpu_add(nmi_stats.external, 1); 
return, 


That's all. 


Range Exceeded Exception 


The next exception is the BouND range exceeded exception. The BouND instruction 
determines if the first operand (array index) is within the bounds of an array specified the 
second operand (bounds operand). If the index is not within bounds, a BouND range 
exceeded exception or #BR is occurred. The handler of the #sr exception is the 

do_bounds function that defined in the arch/x86/kernel/traps.c. The do_bounds handler 
starts with the call of the exception_enter function and ends with the call of the 


exception_exit 


prev_state = exception_enter(); 


if (notify_die(DIE_TRAP, "bounds", regs, error_code, 
X86_TRAP_BR, SIGSEGV) == NOTIFY_STOP) 
goto exit; 


exception_exit(prev_state); 
return; 


After we have got the state of the previous context, we add the exception to the notify_die 
chain and if it will return NoTIFY_STOP we return from the exception. More about notify chains 
and the context tracking functions you can read in the previous part. In the next step we 
enable interrupts if they were disabled with the contidional_sti function that checks IF 
flag and call the local_irq_enable depends on its value: 


conditional_sti(regs); 


if (!user_mode(regs) ) 
die("bounds", regs, error_code); 


and check that if we didn't came from user mode we send _ sicsecv signal with the die 
function. After this we check is MPX enabled or not, and if this feature is disabled we jump 
onthe exit_trap label: 


if (!cpu_feature_enabled(X86_FEATURE_MPX)) { 
goto exit_trap; 


} 
where we execute ‘do trap. function (more about it you can find in the previous part): 


TE 

exit_trap: 
do_trap(X86_TRAP_BR, SIGSEGV, "bounds", regs, error_code, NULL); 
exception_exit(prev_state); 


If mpx feature is enabled we check the BNDSTATUS with the get_xsave_field_ptr function 
and if it is zero, it means that the mpx was not responsible for this exception: 


bndcsr = get_xsave_field_ptr(XSTATE_BNDCSR); 
if (!bndcsr) 
goto exit_trap; 


After all of this, there is still only one way when mpx is responsible for this exception. We 
will not dive into the details about Intel Memory Protection Extensions in this part, but will 
see it in another chapter. 


Coprocessor exception and SIMD exception 


The next two exceptions are x87 FPU Floating-Point Error exception or #mF and SIMD 
Floating-Point Exception or #xF . The first exception occurs when the xs7 FPU has 
detected floating point error. For example divide by zero, numeric overflow and etc. The 
second exception occurs when the processor has detected SSE/SSE2/SSE3 SIMD floating- 
point exception. It can be the same as for the xs7 Feu . The handlers for these exceptions 
are do_coprocessor_error and do_simd_coprocessor_error are defined in the 
arch/x86/kernel/traps.c and very similar on each other. They both make a call of the 
math_error function from the same source code file but pass different vector number. The 
do_coprocessor_error passes x86 TRAP MF vector number to the math_error : 


dotraplinkage void do_coprocessor_error(struct pt_regs *regs, long error_code) 


{ 


enum ctx_state prev_state,; 


prev_state = exception_enter(); 
math_error(regs, error_code, X86_TRAP_MF); 
exception_exit(prev_state); 


and do_simd_coprocessor_error passes xs6_TRAP_xF tothe math_error function: 


dotraplinkage void 


ac aren ec 
ago_simd_coproc 





error(struct pt_regs *regs, long error_code) 


{ 
enum ctx_state prev_state,; 
prev_state = exception_enter(); 
math_error(regs, error_code, X86_TRAP_XF); 
exception_exit(prev_state); 

} 


First of all the math_error function defines current interrupted task, address of its fpu, string 
which describes an exception, add it to the notify_die chain and return from the exception 
handler if it will return NoTIFY_sToP : 


struct task_struct *task = current; 

struct fpu *fpu = &task->thread.fpu; 

siginfo_t info; 

char *str = (trapnr == X86_TRAP_MF) ? "fpu exception" 
"simd exception"; 


if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, SIGFPE) == NOTIFY_STOP) 
return; 


After this we check that we are from the kernel mode and if yes we will try to fix an exception 
with the fixup_exception function. If we cannot we fill the task with the exception's error 
code and vector number and die: 


if (!user_mode(regs)) { 
if (!fixup_exception(regs)) { 
task->thread.error_code = error_code; 
task->thread.trap_nr = trapnr; 
die(str, regs, error_code); 
} 


return; 


If we came from the user mode, we save the fpu state, fill the task structure with the vector 
number of an exception and siginfo_t with the number of signal, errno , the address 
where exception occurred and signal code: 


fpu__save(fpu); 

task->thread.trap_nr = trapnr; 
task->thread.error_code = error_code; 
info.si_signo = SIGFPE; 
info.si_errno = 10" 


info.si_addr = (void __user *)uprobe_get_trap_addr(regs); 
info.si_code = fpu__exception_code(fpu, trapnr); 


After this we check the signal code and if it is non-zero we return: 


if (!info.si_code) 
return; 


Or send the SiIGFPE signal in the end: 


force_sig_info(SIGFPE, &info, task); 


That's all. 


Conclusion 


It is the end of the sixth part of the Interrupts and Interrupt Handling chapter and we saw 
implementation of some exception handlers in this part, like non-maskable interrupt, SIMD 
and x87 FPU floating point exception. Finally we have finsihed with the trap_init function 
in this part and will go ahead in the next part. The next our point is the external interrupts 
and the early_irg_init function from the init/main.c. 


If you have any questions or suggestions write me a comment or ping me at twitter. 


Please note that English is not my first language, And | am really sorry for any 
inconvenience. If you find any mistakes please send me PR to linux-insides. 
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Interrupts and Interrupt Handling. Part 7. 


Introduction to external interrupts 


This is the seventh part of the Interrupts and Interrupt Handling in the Linux kernel chapter 
and in the previous part we have finished with the exceptions which are generated by the 
processor. In this part we will continue to dive to the interrupt handling and will start with the 
external hardware interrupt handling. As you can remember, in the previous part we have 
finished with the trap_init function from the arch/x86/kernel/trap.c and the next step is the 
call of the early_irg_init function from the init/main.c. 


Interrupts are signal that are sent across IRQ or Interrupt Request Line by a hardware or 
software. External hardware interrupts allow devices like keyboard, mouse and etc, to 
indicate that it needs attention of the processor. Once the processor receives the Interrupt 
Request , it will temporary stop execution of the running program and invoke special routine 
which depends on an interrupt. We already know that this routine is called interrupt handler 
(or how we will call it ISR Or Interrupt Service Routine from this part). The Isr or 

Interrupt Handler Routine can be found in Interrupt Vector table that is located at fixed 
address in the memory. After the interrupt is handled processor resumes the interrupted 
process. At the boot/initialization time, the Linux kernel identifies all devices in the machine, 
and appropriate interrupt handlers are loaded into the interrupt table. As we saw in the 
previous parts, most exceptions are handled simply by the sending a Unix signal to the 
interrupted process. That's why kernel is can handle an exception quickly. Unfortunately we 
can not use this approach for the external hardware interrupts, because often they arrive 
after (and sometimes long after) the process to which they are related has been suspended. 
So it would make no sense to send a Unix signal to the current process. External interrupt 
handling depends on the type of an interrupt: 


e 1/o interrupts; 
e Timer interrupts; 
e |nterprocessor interrupts. 


| will try to describe all types of interrupts in this book. 


Generally, a handler of an 1/o interrupt must be flexible enough to service several devices 
at the same time. For example in the PC! bus architecture several devices may share the 
same IRQ line. In the simplest way the Linux kernel must do following thing when an _ 1/0 
interrupt occurred: 


e Save the value of an IrQ® and the register's contents on the kernel stack; 


e Send an acknowledgment to the hardware controller which is servicing the Ire line; 

e Execute the interrupt service routine (next we will call it rsr ) which is associated with 
the device; 

e Restore registers and return from an interrupt; 


Ok, we know a little theory and now let's start with the early_irq init function. The 
implementation of the early_irg_init function is in the kernel/irq/irqdesc.c. This function 
make early initialization of the irq desc structure. The irq desc structure is the foundation 
of interrupt management code in the Linux kernel. An array of this structure, which has the 
same name - irq_desc , keeps track of every interrupt request source in the Linux kernel. 
This structure defined in the include/linux/irqdesc.h and as you can note it depends on the 

CONFIG_SPARSE_IRQ kernel configuration option. This kernel configuration option enables 
support for sparse irqs. The irq desc structure contains many different files: 


e irq common data - per irq and chip data passed down to chip functions; 

e status_use_accessors - contains status of the interrupt source which is combination of 
the values from the enum from the include/linux/irg.h and different macros which are 
defined in the same source code file; 

è kstat_irgs -irq stats per-cpu; 

èe handle irq - highlevel irq-events handler; 

e action -identifies the interrupt service routines to be invoked when the IRQ occurs; 

e irq count - counter of interrupt occurrences on the IRQ line; 

e depth - © if the IRQ line is enabled and a positive value if it has been disabled at 
least once; 

e last_unhandled - aging timer for unhandled count; 

e irqs_unhandled - count of the unhandled interrupts; 

èe lock -a spin lock used to serialize the accesses to the 1rq descriptor; 

e pending_mask - pending rebalanced interrupts; 

e owner - an owner of interrupt descriptor. Interrupt descriptors can be allocated from 
modules. This field is need to proved refcount on the module which provides the 
interrupts; 

e and etc. 


Of course it is not all fields of the irq_desc structure, because it is too long to describe each 
field of this structure, but we will see it all soon. Now let's start to dive into the 
implementation of the early_irq_init function. 


Early external interrupts initialization 


Now, let's look on the implementation of the early_irq_init function. Note that 
implementation of the early_irq_init function depends on the coNFIG SPARSE IRQ kernel 
configuration option. Now we consider implementation of the early_irq_init function when 
the cCONFIG_SPARSE_IRQ kernel configuration option is not set. This function starts from the 
declaration of the following variables: irq descriptors counter, loop counter, memory node 
and the irq_desc descriptor: 


Inte Sme earl yame t (void) 


{ 
int count, i, node = first_online_node; 
struct irq_desc *desc; 


The node is an online NUMA node which depends on the max numnopes value which 
depends on the coNFIG NoDES SHIFT kernel configuration parameter: 


#define MAX_NUMNODES (1 << NODES_SHIFT) 


#ifdef CONFIG_NODES_SHIFT 


#define NODES_SHIFT CONFIG_NODES_SHIFT 
#else 

#define NODES_SHIFT 0 
#endif 


As | already wrote, implementation of the first_online_node macro depends on the 


MAX_NUMNODES value: 


#if MAX_NUMNODES > 1 


#define first_online_node first_node(node_states[N_ONLINE]) 
#else 
#define first_online_node 0 


The node_states is the enum which defined in the include/linux/nodemask.h and represent 
the set of the states of a node. In our case we are searching an online node and it will be o 
if MAX_NUMNODES is One or zero. If the MAX_NUMNODES is greater than one, the 

node_states[N_ONLINE] will return 1 andthe first_node macro will be expands to the call 
of the _ first node function which will return minimal or the first online node: 


#define first_node(src) _ first_node(&(src)) 


static inline int first_node(const nodemask_t *srcp) 


{ 
return min_t(int, MAX_NUMNODES, find_first_bit(srcp->bits, MAX _NUMNODES) ); 


More about this will be in the another chapter about the numa . The next step after the 
declaration of these local variables is the call of the: 


init_irgq_default_affinity(); 


function. The init_irq_default_affinity function defined in the same source code file and 
depends on the conric_smp kernel configuration option allocates a given coumask structure 
(in our case it is the irq _default_affinity ): 


#if defined(CONFIG_SMP) 
cpumask_var_t irq_default_affinity; 


static void _ init init_irgq_default_affinity(void) 

{ 
alloc_cpumask_var(&irq_default_affinity, GFP_NOWAIT); 
cpumask_setall(irq_default_affinity); 


} 
#else 


static void _ init init_irq_default_affinity(void) 
{ 


} 
#endif 


We know that when a hardware, such as disk controller or keyboard, needs attention from 
the processor, it throws an interrupt. The interrupt tells to the processor that something has 
happened and that the processor should interrupt current process and handle an incoming 
event. In order to prevent multiple devices from sending the same interrupts, the IRQ system 
was established where each device in a computer system is assigned its own special IRQ so 
that its interrupts are unique. Linux kernel can assign certain IRQs to specific processors. 
This is known as smP IRQ affinity , and it allows you control how your system will respond 
to various hardware events (that's why it has certain implementation only if the CONFIG_SMP 
kernel configuration option is set). After we allocated irq_default_affinity Cpumask, we 
can see printk output: 


printk(KERN_INFO "NR_IRQS:%d\n", NR_IRQS); 


which prints NR_IRQS : 


~$ dmesg | grep NR_IRQS 
[ 0.000000] NR_IRQS: 4352 


The NR_IRQSs is the maximum number of the irq descriptors or in another words maximum 


number of interrupts. Its value depends on the state of the coNFIG_x86_I0_APIC kernel 


configuration option. If the coNFIG_x86_Io_APIC is not set and the Linux kernel uses an old 


PIC chip, the NR_IRQS is: 


#define 


NR_IRQS_LEGACY 


#ifdef CONFIG_X86_IO_APIC 


#else 


# define NR_IRQS 


#endif 
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NR_IRQS_LEGACY 


In other way, when the coNFIG_x86_I0_APIC kernel configuration option is set, the NR_IRQS 


depends on the amount of the processors and amount of the interrupt vectors: 


#define 
#define 
#define 
#define 


CPU_VECTOR_LIMIT 


# define NR_IRQS 


(64 * NR_CPUS) 


NR_VECTORS 256 

IO_APIC_VECTOR_LIMIT ( 32 * MAX_IO_APICS ) 

MAX_IO_APICS 128 

(CPU_VECTOR_LIMIT > IO_APIC_VECTOR_LIMIT ? \ 
(NR_VECTORS + CPU_VECTOR_LIMIT) : \ 


(NR_VECTORS + IO_APIC_VECTOR_LIMIT) ) 


We remember from the previous parts, that the amount of processors we can set during 


Linux kernel configuration process with the coNFIG_NR_cPUS configuration option: 


深入 外 部 硬件 中 断 


File Edit View Search Terminal Help 


Processor type and features 
Arrow keys navigate the menu. <Enter> selects submenus ---> (or empty 
submenus ----). Highlighted letters are hotkeys. Pressing <Y> 
includes, <N> excludes, <M> modularizes features. Press <Esc><Esc> to 
exit, <?> for Help, </> for Search. Legend: [*] built-in [ ] 
ot 
Processor family (Generic-x86-64) ---> 
[*] Supported processor vendors ---> 
[*] Enable DMI scanning 
[ ] IBM Calgary IOMMU support 
[ ] Enable Maximum number of SMP Processors and NUMA Nodes 
(E) Maximum number of CPUs| 
[ ] SMT (Hyperthreading) scheduler support 
[*] Multi-core scheduler support 
Preemption Model (Voluntary Kernel Preemption (Desktop) ) 
[*] Reroute for broken boot IRQs 
L(+) 


< EXIT > < Help > < Save > < Load > 





In the first case ( CPU_VECTOR_LIMIT > IO_APIC_VECTOR_LIMIT ), the NR_IRQS willbe 4352 , in 
the second case ( CPU_VECTOR_LIMIT < IO_APIC_VECTOR_LIMIT ), the NR_IRQS willbe 768 . In 
my case the nr_cpus iS 8 as you can see in the my configuration, the cPu_vECTOR_LIMIT 
is 512 andthe 10 ApIC VECTOR LIMIT iS 4096 . SO NR_IRQS for my configuration is 4352 : 


~$ dmesg | grep NR_IRQS 
[ 0.000000] NR_IRQS:4352 


In the next step we assign array of the IRQ descriptors to the irq_desc variable which we 
defined in the start of the early_irg_init function and calculate count of the irg_desc 
array with the ARRAY_SIZE macro: 


desc = irq_desc; 
count = ARRAY_SIZE(irq_desc); 


The irq_desc array defined in the same source code file and looks like: 


struct irq_desc irq_desc[NR_IRQS] __cacheline_aligned_in_smp = { 





[9 ... NR_IRQS-1] = { 

-handle_irg = handle_bad_irq, 

. depth = 1, 

.lock = _ RAW_SPIN_LOCK_UNLOCKED(irq_desc->lock), 
} 


}; 


The irq_desc is array of the irq descriptors. lt has three already initialized fields: 
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e handle_irq -as | already wrote above, this field is the highlevel irq-event handler. In 
our case it initialized with the handle_bad_irg function that defined in the 
kernel/irq/nandle.c source code file and handles spurious and unhandled irqs; 

e depth - © if the IRQ line is enabled and a positive value if it has been disabled at 
least once; 

e lock -A spin lock used to serialize the accesses to the irq descriptor. 


As we calculated count of the interrupts and initialized our irq_desc array, we start to fill 
descriptors in the loop: 


for (i = 0; i < count; i++) { 
desc[i].kstat_irgs = alloc_percpu(unsigned int); 
alloc_masks(&desc[i], GFP_KERNEL, node); 
raw_spin_lock_init(&desc[i].lock); 
lockdep_set_class(&desc[i].lock, &irq_desc_lock_class); 
desc_set_defaults(i, &desc[i], node, NULL); 


We are going through the all interrupt descriptors and do the following things: 


First of all we allocate percpu variable for the irq kernel statistic with the alloc_percpu 
macro. This macro allocates one instance of an object of the given type for every processor 
on the system. You can access kernel statistic from the userspace via /proc/stat : 


~$ cat /proc/stat 

cpu 207907 68 53904 5427850 14394 © 394 0 0 0 
cpu0 25881 11 6684 679131 1351 0 18 0 0 0 
cpu1 24791 16 5894 679994 2285 0 24000 
cpu2 26321 4 7154 678924 664 © 71 0 0 0 

cpu3 26648 8 6931 678891 414 0 244 0 0 0 


Where the sixth column is the servicing interrupts. After this we allocate coumask for the 
given irq descriptor affinity and initialize the spinlock for the given interrupt descriptor. After 
this before the critical section, the lock will be acquired with a call of the raw_spin_lock and 
unlocked with the call of the raw_spin_unlock . In the next step we call the 

lockdep_set_class macro which set the Lock validator irq_desc_lock_class class for the 
lock of the given interrupt descriptor. More about lockdep , spinlock and other 
synchronization primitives will be described in the separate chapter. 


In the end of the loop we call the desc_set_defaults function from the kernel/irq/irqdesc.c. 
This function takes four parameters: 


e number of a irq; 

e interrupt descriptor; 

e online numa node; 

e owner of interrupt descriptor. Interrupt descriptors can be allocated from modules. This 
field is need to proved refcount on the module which provides the interrupts; 


and fills the rest of the irq desc fields. The desc_set_defaults function fills interrupt 
number, irq chip, platform-specific per-chip private data for the chip methods, per-IRQ 
data for the irq chip methods and MSI descriptor for the per irq and irq chip data: 


desc->irq_data.irg = irq; 
desc->irq_data.chip = &no_irq_chip; 
desc->irq_data.chip_data = NULL; 
desc->irq_data.handler_data = NULL; 
desc->irq_data.msi_desc = NULL; 


The irgq_data.chip structure provides general apr like the irq _set_chip , 
irq_set_irq_type and etc, for the irq controller drivers. You can find it in the kernel/irq/chip.c 
source code file. 


After this we set the status of the accessor for the given descriptor and set disabled state of 
the interrupts: 


irgq_settings_clr_and_set(desc, ~O, _IRQ_DEFAULT_INIT_FLAGS); 
irqd_set(&desc->irq_data, IRQD_IRQ DISABLED); 


In the next step we set the high level interrupt handlers to the handle_bad_irq which 
handles spurious and unhandled irgs (as the hardware stuff is not initialized yet, we set this 
handler), set irq_desc.desc to 1 which means that an trq is disabled, reset count of the 
unhandled interrupts and interrupts in general: 


desc->handle_irg = handle_bad_irq; 
desc->depth = 1; 

desc->irq_count = 0; 
desc->irqs_unhandled = 0; 
desc->name = NULL; 


desc->owner = owner 7 


After this we go through the all possible processor with the for each possible cpu helper 
and set the kstat_irqs to zero for the given interrupt descriptor: 


for_each_possible_cpu(cpu) 
*per_cpu_ptr(desc->kstat_irqs, cpu) = 0; 


and call the desc_smp_init function from the kernel/irq/irqdesc.c that initializes numa node 
of the given interrupt descriptor, sets default smp affinity and clears the pending_mask of 
the given interrupt descriptor depends on the value of the conFIG_GENERIC_PENDING_IRQ 
kernel configuration option: 


static void desc_smp_init(struct irgq_desc *desc, int node) 
{ 
desc->irg_data.node = node; 
cpumask_copy(desc->irq_data.affinity, irq_default_affinity); 
#ifdef CONFIG_GENERIC_PENDING_IRQ 
cpumask_clear(desc->pending_mask) ; 
#endif 
} 


In the end of the early irq_init function we return the return value of the 
arch_early_irq_init function: 


return arch_early_irq_init(); 


This function defined in the kerne|/apic/vector.c and contains only one call of the 
arch_early_ioapic_init function from the kernel/apic/io_apic.c. AS we can understand from 





the arch_early_ioapic_init function's name, this function makes early initialization of the 





IO APIC. First of all it make a check of the number of the legacy interrupts with the call of 
the nr_legacy_irgs function. If we have no legacy interrupts with the Intel 8259 
programmable interrupt controller we set io apic irqs tothe Qxffffffffffffffff : 


if (!nr_legacy_irqs()) 
io_apic_irqs = ~QUL; 


After this we are going through the all 1/o apics and allocate space for the registers with 
the call of the alloc_ioapic_saved_registers 





for_each_ioapic(i) 





alloc_ioapic_saved_registers(i); 


And in the end of the arch_early_ioapic_init function we are going through the all legacy 





irqs (from irae to IrRQ15 ) in the loop and allocate space for the irgq_cfg which represents 
configuration of an irq on the given numa node: 


for (i = 0; i < nr_legacy_irqs(); i++) { 
cfg = alloc_irq_and_cfg_at(i, node); 
cfg->vector = IRQO_VECTOR + i; 
cpumask_setall(cfg->domain) ; 


That's all. 


Sparse IRQs 


We already saw in the beginning of this part that implementation of the early_irq_init 
function depends on the coNFIG SPARSE IRQ® kernel configuration option. Previously we saw 
implementation of the early_irq_init function when the coNFIG SPARSE_IRQ® configuration 
option is not set, now let's look on the its implementation when this option is set. 
Implementation of this function very similar, but little differ. We can see the same definition of 
variables and call of the init_irq_default_affinity in the beginning of the early irq init 
function: 


#ifdef CONFIG_SPARSE_IRQ 

int __init early_irg_init(void) 

{ 
int i, initcnt, node = first_online_node; 
struct irg_desc *desc; 


init_irg_default_affinity(); 


#else 


But after this we can see the following call: 


initcnt = arch_probe_nr_irqs(); 


The arch_probe_nr_irgs function defined in the arch/x86/kernel/apic/vector.c and calculates 
count of the pre-allocated irqs and update nr_irgs with its number. But stop. Why there are 
pre-allocated irqs? There is alternative form of interrupts called - Message Signaled 
Interrupts available in the PCI. Instead of assigning a fixed number of the interrupt request, 
the device is allowed to record a message at a particular address of RAM, in fact, the display 
on the Local APIC. mst permits a device to allocate 1, 2, 4, 8, 16 or 32 interrupts 
and ms1-x permits a device to allocate up to 2048 interrupts. Now we know that irqs can 
be pre-allocated. More about MsI will be in a next part, but now let's look on the 
arch_probe_nr_irgs function. We can see the check which assign amount of the interrupt 
vectors for the each processor in the system to the nr_irgs if it is greater and calculate the 
nr which represents number of MsI interrupts: 


int nr_irqs = NR_IRQS; 


if (nr_irqs > (NR_VECTORS * nr_cpu_ids) ) 
nr_irqs = NR_VECTORS * nr_cpu_ids; 


nr = (gsi_top + nr_legacy_irqs()) + 8 * nr_cpu_ids; 


Take a look on the gsi top variable. Each apic is identified with its own ID and with the 
offset where its IrQ starts. Itis called csr base or Global system Interrupt base. So the 
gsi_top represents it. We get the Global system Interrupt base from the MultiProcessor 
Configuration Table table (you can remember that we have parsed this table in the sixth part 

of the Linux Kernel initialization process chapter). 


After this we update the nr depends on the value of the gsi_top : 


#if defined(CONFIG_PCI_MSI) || defined(CONFIG_HT_IRQ) 


if (gsi_top <= NR_IRQS_LEGACY) 


nr += 8 * nr_cpu_ids; 
elise 


nr += gsi_top * 16; 
#endif 


Update the nr_irqs ifitless than nr and return the number of the legacy irqs: 


if (nr < nr_irqs) 


nr_irqs = nr; 
return nr_legacy_irqs(); 


} 


The next after the arch_probe_nr_irgs is printing information about number of IRQs : 


printk(KERN_INFO "NR_IRQS:%d nr_irgs:%d %d\n", NR_IRQS, nr_irqs, initcnt); 


We can find it in the dmesg output: 


$ dmesg | grep NR_IRQS 
[ 0.000000] NR_IRQS:4352 nr_irqs:488 16 


After this we do some checks that nr_irqs and initcnt values is not greater than 
maximum allowable number of iras : 


if (WARN_ON(nr_irqs > IRQ_BITMAP_BITS) ) 
nr_irqs = IRQ _BITMAP_BITS; 


if (WARN_ON(initcnt > IRQ_BITMAP_BITS) ) 
initcnt = IRQ_BITMAP_BITS; 


where IRQ _BITMAP_BITS iS equal to the NR_IRQS if the coNFIG SPARSE_IRQ is not set and 
NR_IRQS + 8196 in other way. In the next step we are going over all interrupt descriptors 


which need to be allocated in the loop and allocate space for the descriptor and insert to the 
irq_desc_tree radix tree: 


for (i = 0; i < initcnt; i++) { 
desc = alloc_desc(i, node, NULL); 
set_bit(i, allocated_irqs); 
irq_insert_desc(i, desc); 


In the end of the early_irq_init function we return the value of the call of the 
arch_early_irq_init function as we did it already in the previous variant when the 
CONFIG_SPARSE_IRQ Option was not set: 


return arch_early_irq_init(); 


That's all. 


Conclusion 


It is the end of the seventh part of the Interrupts and Interrupt Handling chapter and we 
started to dive into external hardware interrupts in this part. We saw early initialization of the 

irq_desc structure which represents description of an external interrupt and contains 
information about it like list of irq actions, information about interrupt handler, interrupt's 
owner, count of the unhandled interrupt and etc. In the next part we will continue to research 
external interrupts. 


If you have any questions or suggestions write me a comment or ping me at twitter. 


Please note that English is not my first language, And | am really sorry for any 
inconvenience. If you find any mistakes please send me PR to linux-insides. 


Links 


e IRQ 

e numa 

e Enum type 

e cpumask 

e percpu 

e Spinlock 

e critical section 
e Lock validator 
e MSI 

e I/O APIC 


深入 外 部 硬件 中 断 


e Local APIC 

e Intel 8259 

e PIC 

e MultiProcessor Configuration Table 
e radix tree 

e dmesg 
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Interrupts and Interrupt Handling. Part 8. 


Non-early initialization of the IRQs 


This is the eighth part of the Interrupts and Interrupt Handling in the Linux kernel chapter and 
in the previous part we started to dive into the external hardware interrupts. We looked on 
the implementation of the early_irg_init function from the kernel/irq/irqdesc.c source code 
file and saw the initialization of the irq desc structure in this function. Remind that 

irq_desc structure (defined in the include/linux/irqdesc.h is the foundation of interrupt 
management code in the Linux kernel and represents an interrupt descriptor. In this part we 
will continue to dive into the initialization stuff which is related to the external hardware 
interrupts. 


Right after the call of the early_irg_init function in the init/main.c we can see the call of 
the init_IRQ function. This function is architecture-specific and defined in the 
arch/x86/kernel/irginit.c. The :init_IRQ function makes initialization of the vector_irg 
percpu variable that defined in the same arch/x86/kernel/irginit.c source code file: 


DEFINE_PER_CPU(vector_irg_t, vector_irq) = { 
[0 ... NR_VECTORS - 1] = -1, 
J; 


and represents percpu array of the interrupt vector numbers. The vector_irqt defined in 
the arch/x86/include/asm/hw_irq.h and expands to the: 


typedef int vector_irq_t[NR_VECTORS]; 


where NR_VECTORS is count of the vector number and as you can remember from the first 
part of this chapter itis 256 for the x86 64: 


#define NR_VECTORS 256 


So, in the start of the :init_IRQ function we fill the vector irq percpu array with the vector 
number of the legacy interrupts: 


void __init init_IRQ(void) 


{ 
IME ale 
for (i = 0; i < nr_legacy_irqs(); i++) 
per_cpu(vector_irg, 9)[IRQO_VECTOR + i] = i; 
} 


This vector_irq will be used during the first steps of an external hardware interrupt 
handling in the do_IRQ function from the arch/x86/kernel/irq.c: 


__visible unsigned int irq entry do_IRQ(struct pt regs *regs) 


{ 
irq = _ this cpu_read(vector_irq[vector]); 
if (!handle irq(irq, regs)) { 
} 
exiting_irq(); 
return 1; 
} 


Why is legacy here? Actually all interrupts are handled by the modern IO-APIC controller. 
But these interrupts (from ox30 to ox3f ) by legacy interrupt-controllers like Programmable 
Interrupt Controller. If these interrupts are handled by the 1/0 apic then this vector space 
will be freed and re-used. Let's look on this code closer. First of all the nr_legacy_irgs 
defined in the arch/x86/include/asm/i8259.h and just returns the nr_legacy_irqs field from 
the legacy_pic structure: 


static inline int nr_legacy_irqs(void) 
{ 


return legacy_pic->nr_legacy_irqs; 


This structure defined in the same header file and represents non-modern programmable 
interrupts controller: 


struct legacy_pic { 
int nr_legacy_irqs; 
struct irgq_chip *chip; 
void (*mask)(unsigned int irq); 
void (*unmask)(unsigned int irq); 
void (*mask_all)(void); 
void (*restore_mask) (void); 
void (*init)(int auto_eoi); 
int (*irq_pending)(unsigned int irq); 
void (*make_irq)(unsigned int irq); 


}; 


Actual default maximum number of the legacy interrupts represented by the NR_IRQ_LEGACY 
macro from the arch/x86/include/asm/irq_vectors.h: 


#define NR_IRQS_LEGACY 16 


In the loop we are accessing the vecto_irq per-cpu array with the per_cpu macro by the 
IRQO_VECTOR + i index and write the legacy vector number there. The IRQe_vEcTOoR macro 
defined in the arch/x86/include/asm/irq_vectors.h header file and expands to the 0x30 : 


#define FIRST_EXTERNAL_VECTOR 0x20 


#define IRQO_ VECTOR ((FIRST_EXTERNAL_VECTOR + 16) & ~15) 


Why is ox30 here? You can remember from the first part of this chapter that first 32 vector 
numbers from o to 31 are reserved by the processor and used for the processing of 
architecture-defined exceptions and interrupts. Vector numbers from ox30 to ox3f are 
reserved for the ISA. So, it means that we fill the vector_irq fromthe Irqe_vector which is 
equal to the 32 tothe rrgo_vector + 16 (before the ox30 ). 


In the end of the init_IRQ function we can see the call of the following function: 


x86_init.irgs.intr_init(); 


from the arch/x86/kernel/x86_init.c source code file. If you have read chapter about the 
Linux kernel initialization process, you can remember the xs6_init structure. This structure 
contains a couple of files which are points to the function related to the platform setup 

( x86_64 in our case), for example resources - related with the memory resources, 


mpparse - related with the parsing of the MultiProcessor Configuration Table table and etc.). 
As we can see the x86_init also contains the irgs field which contains three following 
fields: 


struct x86_init_ops x86_init __initdata 


{ 
.irqs = { 
.pre_vector_init = init_ISA_irgs, 
.intr_init = native_init_IRQ, 
.trap_init = x86_init_noop, 
}, 
} 


Now, we are interesting in the native_init_IRQ . As we can note, the name of the 
native_init_IRQ function contains the native_ prefix which means that this function is 
architecture-specific. It defined in the arch/x86/kernel/irginit.c and executes general 
initialization of the Local APIC and initialization of the ISA irqs. Let's look on the 
implementation of the native_init_IRQ function and will try to understand what occurs 
there. The native_init_IRQ function starts from the execution of the following function: 


x86_init.irgs.pre_vector_init(); 


As we can see above, the pre_vector_init points tothe init_1sa_irqs function that 
defined in the same source code file and as we can understand from the function's name, it 
makes initialization of the rīsa related interrupts. The init_tsa_irqs function starts from 
the definition of the chip variable which has a irq chip type: 


void imit init_ISA_irqs(void) 
{ 


struct irq_chip *chip = legacy_pic->chip; 


The irq_chip structure defined in the include/linux/irg.h header file and represents 
hardware interrupt chip descriptor. It contains: 


e name -name of a device. Used in the /proc/interrupts : 


$ cat /proc/interrupts 


CPUO CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 
CPU7 
0: 16 0 0 0 0 0 0 
0 IO-APIC 2-edge timer 
akg 2 0 0 0 0 0 0 
0 IO-APIC 1-edge 18042 
8 all 0 0 0 0 0 0 
0 IO-APIC 8-edge rtco 


look on the last column; 


e (*irg_mask)(struct irq_data *data) - mask an interrupt source; 
e (*irq_ack)(struct irq_data *data) - Start of a new interrupt; 

èe (*irg_startup)(struct irq_data *data) - Start up the interrupt; 

e (*irg_shutdown)(struct irq_data *data) - Shutdown the interrupt 


and etc. 


fields. Note that the irq_data structure represents set of the per irq chip data passed down 
to chip functions. It contains mask - precomputed bitmask for accessing the chip registers, 

irq -interrupt number, hwirg - hardware interrupt number, local to the interrupt domain 
chip low level interrupt hardware access and etc. 


After this depends on the conF1c_xs6_64 and coNFIG x86 LOCAL APIC kernel configuration 
option call the init_bsp_apic function from the arch/x86/kernel/apic/apic.c: 


#if defined(CONFIG_X86_64) || defined(CONFIG_X86_LOCAL_APIC) 
init_bsp_APIC(); 
#endif 


This function makes initialization of the APIC of bootstrap processor (or processor which 
starts first). It starts from the check that we found SMP config (read more about it in the sixth 
part of the Linux kernel initialization process chapter) and the processor has APIC : 


if (smp_found_config || !cpu_has_apic) 
return; 


In other way we return from this function. In the next step we call the clear_ local APIC 
function from the same source code file that shutdowns the local APIc (more about it will be 
in the chapter about the Advanced Programmable Interrupt Controller ) and enable apic of 
the first processor by the setting unsigned int value to the APIC_SPIV_APIC_ENABLED : 


value = apic_read(APIC_SPIV); 
value &= ~APIC_VECTOR_MASK; 
value |= APIC_SPIV_APIC_ENABLED; 


and writing it with the help of the apic_write function: 


apic_write(APIC_SPIV, value); 


After we have enabled apic for the bootstrap processor, we return to the :init_ISA_irqs 
function and in the next step we initialize legacy Programmable Interrupt Controller and set 
the legacy chip and handler for the each legacy irq: 


legacy_pic->init(0); 


for (i = 0; i < nr_legacy_irqs(); i++) 





irq_set_chip_and_handler(i, chip, handle_level_irq); 


Where can we find init function? The legacy_pic defined in the arch/x86/kernel/i8259.c 
and it is: 


struct legacy_pic *legacy_pic = &default_legacy_pic; 


Where the default_legacy_pic is: 


struct legacy_pic default_legacy_pic = { 


,Init = init_8259A, 


The init_s259a function defined in the same source code file and executes initialization of 
the Intel 8259 ~programmable Interrupt Controller (more about it will be in the separate 
chapter about Programmable Interrupt Controllers and APIC ). 


Now we can return to the native_init_IRQ function, after the init_1sA_irgqs function 
finished its work. The next step is the call of the apic_intr_init function that allocates 
special interrupt gates which are used by the SMP architecture for the Inter-processor 
interrupt. The alloc_intr_gate macro from the arch/x86/include/asm/desc.h used for the 
interrupt descriptor allocation: 


#define alloc_intr_gate(n, addr) 
do { 
alloc_system_vector(n); 


Ce ree ee 


set_intr_gate(n, addr); 
} while (0) 


As we can see, first of all it expands to the call of the alloc_system_vector function that 
checks the given vector number in the used_vectors bitmap (read previous part about it) 
and if it is not set in the used_vectors bitmap we set it. After this we test that the 

first_system_vector is greater than given interrupt vector number and if it is greater we 
assign it: 


if (!test_bit(vector, used_vectors)) { 
set_bit(vector, used_vectors); 
if (first_system_vector > vector) 
first_system_vector = vector; 
y else { 
BUG(); 


We already saw the set_bit macro, now let's look on the test_bit and the 
first_system_vector . The first test_bit macro defined in the 
arch/x86/include/asm/bitops.h and looks like this: 


#define test_bit(nr, addr) \ 
(builtin_constant_p((Cnr)) \ 
? constant_test_bit((nr), (addr) ) \ 


: variable_test_bit((nr), (addr))) 


We can see the ternary operator here make a test with the gcc built-in function 
__builtin_constant_p tests that given vector number ( nr ) is Known at compile time. If 
you're feeling misunderstanding of the _ builtin_constant_p , we can make simple test: 


#include <stdio.h> 
#define PREDEFINED_VAL 1 


int main() { 
ine al = iy 
printf("__builtin_constant_p(i) is %d\n", __builtin_constant_p(i)); 
printf("__builtin_constant_p(PREDEFINED_ VAL) is %d\n", _ builtin_constant_p(PREDEF 
INED_VAL) ); 
printf("__builtin_constant_p(100) is %d\n", __builtin_constant_p(100)); 


return 0; 


and look on the result: 


$ gcc test.c -o test 

$ ./test 

__builtin_constant_p(i) is 0 
__builtin_constant_p(PREDEFINED_VAL) is 1 
__builtin_constant_p(100) is 1 


Now | think it must be clear for you. Let's get back to the test_bit macro. If the 
__builtin_constant_p will return non-zero, we call constant_test_bit function: 


static inline int constant_test_bit(int nr, const void *addr) 


{ 


const u32 *p = (const u32 *)addr; 


return ((1UL << (nr & 31)) & (p[nr >> 5])) != 0; 


and the variable_test_bit in other way: 


static inline int variable_test_bit(int nr, const void *addr) 


{ 
u8 vV; 
const u32 *p = (const u32 *)addr; 
asm("btl %2,%1; setc %O0" : "=qm" (v) : "m" (*p), "Ir" (nr)); 
return v; 
} 


What's the difference between two these functions and why do we need in two different 
functions for the same purpose? As you already can guess main purpose is optimization. If 
we will write simple example with these functions: 


#define CONST 25 


int main() { 
ine nr = 24" 

variable_test_bit(nr, (int*)0x10000000); 

constant_test_bit(CONST, (int*)0x10000000) 


return 0: 


and will look on the assembly output of our example we will see following assembly code: 


pushq %rbp 
movq %rsp, %rbp 


movl $268435456, %esi 


movl $25, %edi 
call constant_test_bit 


for the constant_test_bit , and: 


pushq %rbp 
movq %rsp, %rbp 


subq $16, %rsp 
movl $24, -4(%rbp) 


movl -4(%rbp), %eax 
movl $268435456, %esi 
movl %eax, %edi 

call variable_test_bit 


for the variable_test_bit . These two code listings starts with the same part, first of all we 
save base of the current stack frame in the %rbp register. But after this code for both 
examples is different. In the first example we put $268435456 (here the $268435456 is our 
second parameter - ox10000000 ) tothe esi and $25 (our first parameter) to the edi 
register and call constant_test_bit . We put function parameters to the esi and edi 
registers because as we are learning Linux kernel for the x86 64 architecture we use 

System V AMD64 ABI Calling convention. All is pretty simple. When we are using predefined 
constant, the compiler can just substitute its value. Now let's look on the second part. As you 
can see here, the compiler can not substitute value from the nr variable. In this case 
compiler must calculate its offset on the program's stack frame. We subtract 16 from the 

rsp register to allocate stack for the local variables data and put the $24 (value of the nr 
variable) to the rbp with offset -4 . Our stack frame will be like this: 


<- Stack grows 


After this we put this value to the eax ,SO eax register now contains value of the nr . In 
the end we do the same that in the first example, we put the $268435456 (the first parameter 
of the variable_test_bit function) and the value of the eax (value of nr )tothe edi 
register (the second parameter of the variable_test_bit function ). 


The next step after the apic_intr_init function will finish its work is the setting interrupt 
gates from the FIRST_EXTERNAL_VECTOR Or 0x20 tothe ox256 : 


i = FIRST_EXTERNAL_VECTOR; 


#ifndef CONFIG_X86_LOCAL_APIC 
#define first_system_vector NR_VECTORS 
#endif 


for_each_clear_bit_from(i, used_vectors, first_system_vector) { 
set_intr_gate(i, irq_entries_start + 8 * (i - FIRST_EXTERNAL_VECTOR) ); 





But as we are using the for_each_clear_bit_from helper, we set only non-initialized interrupt 
gates. After this we use the same for_each_clear_bit_from helper to fill the non-filled 
interrupt gates in the interrupt table with the spurious_interrupt : 








#ifdef CONFIG_X86_LOCAL_APIC 
for_each_clear_bit_from(i, used_vectors, NR_VECTORS) 





set_intr_gate(i, spurious_interrupt); 
#endif 


Where the spurious_interrupt function represent interrupt handler for the spurious 
interrupt. Here the used_vectors isthe unsigned long that contains already initialized 
interrupt gates. We already filled first 32 interrupt vectors in the trap_init function from 
the arch/x86/kernel/setup.c source code file: 


for (i = 0; i < FIRST_EXTERNAL_VECTOR; i++) 
set_bit(i, used_vectors); 
You can remember how we did it in the sixth part of this chapter. 


In the end of the native_init_IRQ function we can see the following check: 


if (!acpi_ioapic && !of_ioapic && nr_legacy_irqs()) 
setup_irq(2, &irq2); 


First of all let's deal with the condition. The acpi_ioapic variable represents existence of |/O 
APIC. It defined in the arch/x86/kernel/acpi/boot.c. This variable set in the 
acpi_set_irq_model_ioapic function that called during the processing Multiple APIC 





Description Table . This occurs during initialization of the architecture-specific stuff in the 
arch/x86/kernel/setup.c (more about it we will know in the other chapter about APIC). Note 
that the value of the acpi_ioapic variable depends on the coNFIG_AcPI and 

CONFIG_X86_LOCAL_APIc Linux kernel configuration options. If these options did not set, this 
variable will be just zero: 


#define acpi_ioapic 0 


The second condition - !of_ioapic && nr_legacy_irqs() checks that we do not use Open 
Firmware 1/0 APIC and legacy interrupt controller. We already know about the 
nr_legacy_irgs . The second is of_ioapic variable defined in the 

arch/x86/kernel/devicetree.c and initialized in the dtb_ioapic_setup function that build 
information about aprcs inthe devicetree. Note that of_ioapic variable depends on the 
conFIc_oF Linux kernel configuration option. If this option is not set, the value of the 
of_ioapic will be zero too: 


#ifdef CONFIG_OF 
extern int of_ioapic; 


#else 
#define of_ioapic 0 
#endif 


If the condition will return non-zero value we call the: 


setup_irq(2, &irq2); 


function. First of all about the irg2 . The irg2 isthe irqaction structure that defined in 


the arch/x86/kernel/irginit.c source code file and represents IrQ 2 line that is used to query 


devices connected cascade: 


static struct irgaction irq2 = { 


}; 


.handler = no_action, 


,name = "cascade", 
.flags = IRQF_NO_THREAD, 


Some time ago interrupt controller consisted of two chips and one was connected to second. 


The second chip that was connected to the first chip via this īrọ 2 line. This chip serviced 


lines from 8 to 15 and after this lines of the first chip. So, for example Intel 8259A has 


following lines: 


The 


IRQ © - system time; 


IRQ 1 - keyboard; 
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- used for devices which are cascade connected; 
- RTC; 
- reserved; 
- reserved; 
- reserved; 
- ps/2 mouse; 
- coprocessor; 
- hard drive controller; 
- reserved; 
- com2 and coma ; 
- com1 and come ; 
- LPT2; 
- drive controller; 


= BERTI. 


setup_irq function defined in the kernel/irg/manage.c and takes two parameters: 


e vector number of an interrupt; 


irqaction structure related with an interrupt. 


This function initializes interrupt descriptor from the given vector number at the beginning: 


struct irq_desc *desc = irq_to_desc(irq); 


And call the _ setup_irq function that setups given interrupt: 


chip_bus_lock(desc); 

retval = __setup_irq(irg, desc, act); 
chip_bus_sync_unlock(desc) ; 

return retval; 


Note that the interrupt descriptor is locked during _ setup_irq function will work. The 
__setup_irq function makes many different things: It creates a handler thread when a 
thread function is supplied and the interrupt does not nest into another interrupt thread, sets 
the flags of the chip, fills the irqaction structure and many many more. 


All of the above it creates /prov/vector_number directory and fills it, but if you are using 
modern computer all values will be zero there: 


$ cat /proc/irgq/2/node 
0 


$cat /proc/irg/2/affinity_hint 
00 


cat /proc/irgq/2/spurious 
count 0 

unhandled 0 
last_unhandled © ms 


because probably apic handles interrupts on the our machine. 


That's all. 


Conclusion 


It is the end of the eighth part of the Interrupts and Interrupt Handling chapter and we 
continued to dive into external hardware interrupts in this part. In the previous part we 
started to do it and saw early initialization of the IRQs . In this part we already saw non-early 
interrupts initialization in the :init_IRQ function. We saw initialization of the vector_irq per- 
cpu array which is store vector numbers of the interrupts and will be used during interrupt 
handling and initialization of other stuff which is related to the external hardware interrupts. 


In the next part we will continue to learn interrupts handling related stuff and will see 
initialization of the softirgs . 


If you have any questions or suggestions write me a comment or ping me at twitter. 


Please note that English is not my first language, And 1 am really sorry for any 
inconvenience. If you find any mistakes please send me PR to linux-insides. 
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中 断 和 中 断 处 理 ( 九 ) 


EE 后 中 断 ( 软 中 断 ，Tasklets 和 工作 队列 ) 介 绍 


oe mee os 
arch/x86/kernel/irginit.c 中 的 init_IRQ 实现 。 接 下 来 的 这 一 节 我 们 将 继续 深入 学 习 外 部 硬件 
中 断 的 初始 化 。 


中 断 处 理会 有 一 些 特点 ， 其 中 最 主要 的 两 个 是 : 


EE 


o 中 断 处 理 必 须 快 速 执行 完毕 
© 有 时 中 断 处 理 必须 做 很 多 宛 长 的 事情 


就 像 你 所 想到 的 ， 我 们 几乎 不 可 能 同时 做 到 这 两 点 ， 之 前 的 中 断 被 分 为 两 部 分 : 


。 后 半 部 


后 半 部 曾经 是 es a ey 但 现在 的 实际 情况 已 经 不 是 这 样 了 。 现 
在 它 已 作为 一 个 遗留 称谓 代表 内 核 中 所 有 延 后 中 断 的 机 制 。 如 你 所 知 ， 中 断 处 理 代 码 运 行 于 
a eee 卖 的 中 断 ， 所 以 要 避免 中 断 处 理 代码 长 时 间 执 行 。 但 有 
些 中 断 却 又 需要 执行 很 多 工作 ， 所 以 中 断 处 理 有 时 会 被 分 为 两 部 分 。 第 一 部 分 中 ， 中 断 处 理 
先 只 做 尽量 少 的 重要 工作 ， 接 下 来 提交 第 二 部 分 给 内 核 调度 ， 然 后 就 结束 运行 。 当 系统 比较 
空闲 并 且 处 理 器 上 下 文 允许 处 理 中 断 时 ， 第 二 部 分 被 延 后 的 剩余 任务 就 会 开始 执行 。 


当前 实现 延 后 中 断 的 有 如 下 三 种 途径 : 


e kp 
@ tasklets 


@ 工作 队列 


在 这 一 小 节 我 们 将 详细 介绍 这 三 种 实现 ， 现 在 是 时 间 深 入 了 解 一 下 了 。 


软 中 断 


伴随 着 内 核对 并 行 处 理 的 支持 ， 出 于 性 能 考虑 ， 所 有 新 的 下 半 部 实现 方案 都 基于 被 称 之 为 
ksoftirqd ( 稍 后 将 详细 讨论 ) 的 内 核 线程 。 see ed 自己 的 内 核 线程 ， 名 字 叫 做 
ksoftirqd/n ，n 是 处理 器 的 编号 。 我 们 可 以 通过 系统 命 systemd-cgls 看 到 它们 : 


$ systemd-cgls -k | grep ksoft 
一 3 [ksoftirqd/0] 
一 13 [ksoftirqd/1] 
一 18 [ksoftirqd/2] 
一 23 [ksoftirqd/3] 
一 28 [ksoftirqd/4] 
一 33 [ksoftirqd/5] 
一 38 [ksoftirqd/6] 
一 43 [ksoftirqd/7] 





由 spawn_ksoftirqd RÄ E hR ERF o MRR AB > RPS BARES HA initcall 被 调 
用 。 


early_initcall(spawn_ksoftirqd) ; 


软 中 断 在 Linux 内 核 编 译 时 就 静态 地 确定 了 ° open_softirq hy aH 责 softirg 初始 化 > 它 
在 kernel/softirq.c 中 定义 : 


void open_softirq(int nr, void (*action)(struct softirq_action *)) 


{ 
softirg_vec[nr].action = action; 
} 
这 个 函数 有 两 个 参数 : 


© softirq vec 数组 的 索引 序号 
e 一 个 指向 软 中 断 处理 函 数 的 指针 


我 们 首先 来 看 softirq vec 数组 : 


static struct softirq_action softirq_vec[NR_SOFTIRQS] __cacheline_aligned_in_smp; 


它 在 同一 源 文件 中 定义 。 softirq vec 数组 包含 了 NR_SOFTIRQS (其 值 为 10) 个 不 同 softirg 
类 型 的 softirq_action 。 当 前 版 本 的 Linux 内 核定 义 了 十 种 软 中 断 向 量 。 其 中 两 个 tasklet 相 
关 ， 两 个 网 络 相关 ， 两 个 块 处 理 相关 ， 两 个 定时 器 相关 ， 另 外 调度 器 和 RCU 也 各 占 一 个 。 所 
有 这 些 都 在 一 个 枚 举 中 定义 : 


enum 


HI_SOFTIRQ=0, 
TIMER_SOFTIRQ, 
NET_TX_SOFTIRQ, 
NET_RX_SOFTIRQ, 
BLOCK_SOFTIRQ, 
BLOCK_IOPOLL_SOFTIRQ, 
TASKLET_SOFTIRQ, 
SCHED_SOFTIRQ, 
HRTIMER_SOFTIRQ, 
RCU_SOFTIRQ, 
NR_SOFTIRQS 


}; 


以 上 软 中 断 的 名 字 在 如 下 的 数组 中 定义 : 


const char * const softirq_ to_name[NR_SOFTIRQS] = { 
HE TIMER ANETO MINER. Melle ts 
"TASKLET", "SCHED", "HRTIMER", "RCU" 


}; 


我 们 也 可 以 在 /proc/softirqs 的 输出 中 看 到 他 们 : 


~$ cat /proc/softirgs 


CPUO CPU1 CPU2 

CPU6 CPU7 
HI: 5 0 0 

0 0 
TIMER: 332519 310498 289555 

2895 270979 
NET_TX: 2320 0 0 

0 0 
NET_RX: 270221 225 338 

430 265 
BLOCK : 134282 32 40 

8 8 
BLOCK_IOPOLL: 0 0 0 

0 0 
TASKLET: 196835 2 3 

0 0 
SCHED: 161852 146745 129539 

0243 117391 
HRTIMER: 0 0 0 

0 0 
RCU: 337707 289397 251874 


7497 256624 


"BLOCK_IOPOLL", 


CPU3 


272913 


281 


126064 


239796 


CPU4 


282535 


311 


127998 


254377 


CPUS 


279467 


262 


128014 


254898 


28 


12 


26 


可 以 看 到 softirq_vec 数组 的 类 型 为 Softirq_action ° 这 是 软 中 断 机 制 里 一 个 重要 的 数据 结 
构 ， 它 只 有 一 个 指向 中 断 处 理 函 数 的 成 员 : 


struct softirq_action 


{ 


void (*action)(struct softirq_action *); 


}; 


现在 我 们 可 以 理解 到 open_softirq 函数 实际 上 用 softirq action | softirg_vec 
数组 。 由 open_softirgq 注册 的 延 后 中 断 处 理 函 SSH raise _softirg 调用 。 个 函数 只 有 
一 个 参数 -- 软 中 断 序号 nr 。 来 看 下 它 的 实现 : 


void raise_softirq(unsigned int nr) 


{ 
unsigned long flags; 
local_irq_save(flags); 
raise_softirq_irgoff(nr); 
local_irq_restore(flags); 
} 


可 以 看 到 在 local_irq_save 和 local _irq_restore 两 个 宏 中 间 调 用 了 

raise_softirq_irgoff 42° local_irq_save 的 定义 位 于 include/linux/irgflags.h 头 文 件 ， 

它 保 存 了 eflags 寄存 器 中 的 IF 标志 位 并 且 禁 用 了 当前 处 理 器 的 中 断 。 local_irg_restore %& 

定义 于 相同 头 文件 中 ， 它 做 了 完全 相反 的 事情 : 3 装 回 之 前 保存 的 中 断 标志 位 然后 允许 中 断 。 
这 里 之 所 以 要 禁用 中 断 是 因为 将 要 运行 的 softirq 中 断 处理 运 行 于 中 断 上 下 文中 。 


raise_softirq irqoff ein 当前 处 理 器 上 和 nr 参数 对 应 的 软 中 断 标志 位 
( __softirq_pending )。 这 是 通过 以 下 代码 做 到 的 : 


__raise_softirq_irqoff(nr); 


然后 ， 通 过 in_interrupt 函数 获得 irq_count 值 。 我 们 在 这 一 章 的 第 一 小 节 已 经 知道 它 是 
用 来 检测 一 个 cpu aig Aas 如 果 我 们 处 于 中 断 上 下 文中 ， 我 们 就 退出 
raise_softirq_irqoff 函数 ， KE IF 标志 位 并 允许 当前 处 理 器 的 中 断 。 如 果 不 在 中 断 上 下 
文中 ， 就 会 调用 wakeup_softirqd 函数 : 


if (!in_interrupt()) 
wakeup_softirqd(); 


wakeup_softirqd $ 函数 会 激活 当前 处 理 器 上 的 ksoftirqd 内 核 线程 : 


static void wakeup_softirqd(void) 


{ 
struct task_struct *tsk = _ this cpu_read(ksoftirqd); 
if (tsk && tsk->state != TASK_RUNNING) 
wake_up_process(tsk); 
} 


每 个 ksoftirqd 内 核 线程 都 运行 run_ksoftirqd 函数 来 检测 是 否 有 延 后 中 断 需 要 处 理 ， 如 果 
有 的 话 就 会 调用 _do_softirq 函数 。 _do_softirq 读 取 当 前 处 理 器 对 应 的 

_ softirq_pending 软 中 断 标 记 ， 并 调用 所 有 已 被 标记 中 断 对 应 的 处 理 函 数 。 在 执行 一 个 延 后 
函数 的 同时 ， 可 能 会 发 生 新 的 软 中 断 。 这 会 导致 用 户 态 代 码 由 于 do_softirq 要 处 理 很 多 延 
后 中 断 而 很 长 时 间 不 能 返回 。 为 了 解决 这 个 问题 ， 系 统 限 制 了 延 后 中 断 处 理 的 最 大 耗 时 : 


unsigned long end = jiffies + MAX_SOFTIRQ_TIME; 


restart: 
while ((softirq_bit = ffs(pending))) { 


h->action(h); 


pending = local_softirgq_pending(); 
if (pending) { 
if (time_before(jiffies, end) && !need_resched() && 
--max_restart) 
goto restart; 


除 周 期 性 检测 是 否 有 延 后 中 断 需 要 执行 之 外 ， 系 统 还 会 在 一 些 关 键 时 间 点 上 检测 。 一 个 主要 
的 检测 时 间 点 就 是 当 定义 在 arch/x86/kernel/irq.c 的 do_IRQ 函数 被 调用 时 ， 这 是 Linux 内 核 
中 执行 延 后 中 断 的 主要 时 机 。 在 这 个 防 数 将 要 完成 中 断 处 理 时 它 会 调用 
arch/x86/include/asm/apic.h 中 定义 的 exiting_irq Ak? exiting_irq 又 调用 了 

irq_exit ° irq_ exit 函数 会 检测 当前 处 理 器 上 下 文 是 否 有 延 后 + Bý i 有 的 话 就 会 调用 


invoke_softirg 


if (!in_interrupt() && local_softirgq_pending() ) 
invoke_softirq(); 


这 样 就 调用 到 了 我 们 上 面 提 到 的 do softirq ° ÆA softirq 都 有 如 下 的 阶段 : 通过 
open_softirq 函数 注册 一 个 软 中 断 ， 通 过 raise_softirq 函数 标记 一 个 软 中 断 来 激活 它 ， 然 
后 所 有 被 标记 的 软 中 断 将 会 在 Linux 内 核 下 一 次 执行 周期 性 软 中 断 检 测 时 得 以 调度 ， 对 应 此 
类 型 软 中 断 的 处 理 函 数 也 就 得 以 执行 。 


从 上 述 可 看 出 ， 软 中 断 是 静态 分 配 的 ， 这 对 于 后 期 加 载 的 内 核 模 块 将 是 一 个 问题 。 基 于 软 中 
断 实现 的 tasklets 解决 了 这 个 问题 。 


Tasklets 


如 果 你 阅读 Linux 内 核 源码 中 软 中 断 相关 的 代码 ， 你 会 发 现 它 很 少 会 被 用 到 。 内 核 中 实现 延 
后 中 断 的 主要 途径 是 tasklets 。 正 如 上 面 说 的 ， tasklets 构建 于 softirg 中 断 之 上 ， 他 
是 基于 下 面 两 个 软 中 断 实现 的 : 


@ TASKLET_SOFTIRQ 


@ HI_SOFTIRQ . 


fl 7 SZ? tasklets 是 运行 时 分 配 和 初始 化 的 软 中 断 。 和 软 中 断 不 同 的 是 ， 同 一 类 型 的 
tasklets 可 以 在 同一 时 间 运 行 于 不 同 的 处 理 器 上 。 我 们 已 经 了 解 到 一 些 关 于 软 中 断 的 知识 ， 
当然 上 面 的 文字 并 不 能 详细 讲解 所 有 的 细节 ， 但 我 们 现在 可 以 通过 直接 阅读 代码 一 步 步 的 更 
深入 了 解 软 中 断 。 我 们 返回 到 开始 部 分 讨论 的 softirq_init 元 数 实现 ， 这 个 函数 在 
kernel/softirg.c 中 定义 如 下 : 


void __init softirgq_init(void) 
{ 


int cpu; 


for_each_possible_cpu(cpu) { 
per_cpu(tasklet_vec, cpu).tail = 
&per_cpu(tasklet_vec, cpu) .head; 
per_cpu(tasklet_hi_vec, cpu).tail = 
&per_cpu(tasklet_hi_vec, cpu).head; 


} 


open_softirq(TASKLET_SOFTIRQ, tasklet_action); 
open_softirq(HI_SOFTIRQ, tasklet_hi_action); 


可 以 看 到 在 函数 开头 定义 了 一 个 名 为 cpu 的 integer 类 型 变量 。 接 下 来 他 会 作为 参数 传递 给 宏 
for_each_possible_cpu 来 获得 系统 中 所 有 的 处 理 器 。 如 果 possible cpu 对 你 来 说 是 一 个 新 

的 术语 ， 你 可 以 阅读 CPU masks 章节 来 了 解 更 多 知识 。 简 单 的 说 ， possible cpu 是 系统 运 

行 期 间 插入 的 处 理 器 集合 。 所 有 的 possible processor 存储 在 cpu_possible_bits 位 图 中 ， 

你 可 以 在 kernel/cpu.c 中 找到 他 的 定义 : 


static DECLARE_BITMAP(cpu_possible bits, CONFIG_ NR_CPUS) read_mostly; 





const struct cpumask *const cpu_possible_mask = to_cpumask(cpu_possible_bits); 


好 了 ， 我 们 定义 了 integer 类 型 变量 cpu Hii for_each_possible cpu 宏 遍 历 了 所 有 处 
理 器 ， 初 始 化 了 两 个 per-cpu 变量 : 


© tasklet_vec ; 


© tasklet_hi_vec ; 


这 两 个 per-cpu 变量 和 softirq_ init 函数 都 定义 在 相同 代码 中 ， 他 们 被 定义 为 
tasklet_head 类 型 : 


static DEFINE_PER_CPU(struct tasklet_head, tasklet_vec); 
static DEFINE_PER_CPU(struct tasklet_head, tasklet_hi_vec); 


tasklet_head 结构 代表 一 组 Tasklets ， 它 包含 两 个 成 员 ，head 和 tail : 


struct tasklet_head { 
struct tasklet_struct *head; 
struct tasklet_struct **tail; 


}; 


tasklet_struct 数据 类 型 在 include/linux/interrupt.h 中 定义 ， 它 代表 一 个 Tasklet 。 这 本 书 
之 前 部 分 我 们 没有 见 过 这 个 单词 ， 那 我 们 先 试 着 理解 一 下 Tasklet 究 竞 为何 物 。 实 际 
上 ， Tasklet 是 处 理 延 后 中 断 的 一 种 机 制 ， 来 看 一 下 tasklet_struct 的 具体 定义 : 


struct tasklet_struct 


{ 
struct tasklet_struct *next; 
unsigned long state; 
atomic_t count; 
void (*func)(unsigned long); 
unsigned long data; 

J; 


这 个 数据 结构 包含 有 下 面 5 个 成 员 : 


© 调度 队列 中 的 下 一 个 Tasklet 

e 当前 这 个 Tasklet 的 状态 

e 这 个 Tasklet 是 否 处 于 活动 状态 
e Tasklet 的 回调 函数 


© 回调 函数 的 参数 


上 面 代码 中 ， 在 softirq init 函数 中 初始 化 了 两 个 tasklets 数组 : tasklet_vec 和 
tasklet_hi_vec ° Tasklets 和 高 优先 级 Tasklets 分 别 存储 于 这 两 个 数组 中 。 初 始 化 完成 后 我 
们 看 到 代码 kernel/softirg.c Æ softirq_init 函数 的 最 后 又 两 次 调用 了 open_softirg 


open_softirg(TASKLET_SOFTIRQ, tasklet_action); 
open_softirq(HI_SOFTIRQ, tasklet_hi_action); 


open_softirg aay ERAF M Æi PH > HEP RIERMAA CREAM © Fe 
Tasklets 相关 的 软 中 断 处 理 函 数 有 两 个 ， 分 别 是 tasklet_action 和 tasklet_hi_action ° # 
中 tasklet_hi_action 和 HI_SOFTIRQ 关联 在 一 & > tasklet_action 和 TASKLET_SOFTIRQ 关 


联 在 一 起 。 


Linux 内 核 提 供 一 些 API 供 操 作 Tasklets 之 用 。 首 先是 tasklet_init 有 函数 ， 它 接受 一 个 
task_struct 数据 结构 ， 一 个 处 理 函 数 ， 和 另外 一 个 参数 ， 并 利用 这 些 参 数 来 初始 化 所 给 的 


task_struct 结构 : 


void tasklet_init(struct tasklet_struct *t, 
void (*func)(unsigned long), unsigned long data) 


{ 
t->next = NULL; 
t->state = 0; 
atomic_set(&t->count, 0); 
t->func = func; 
t->data = data; 

} 


另外 还 有 如 下 两 个 宏 可 以 静态 地 初始 化 一 个 tasklet : 


DECLARE_TASKLET(name, func, data); 
DECLARE_TASKLET_DISABLED(name, func, data); 


Linux 内 核 提 供 三 个 函数 标记 一 个 tasklet 已 经 准备 就 绪 : 


void tasklet_schedule(struct tasklet_struct *t); 


void tasklet_hi_schedule(struct tasklet_struct *t); 


void tasklet_hi_schedule_first(struct tasklet_struct *t); 


第 一 个 函数 使 用 普通 优先 级 调度 一 个 tasklet， 第 二 个 使 用 高 优先 级 ， 第 三 个 则 用 更 高 优先 
级 。 所 有 这 三 个 函数 的 实现 都 很 类 似 ， 所 以 我 们 只 看 一 下 第 一 个 tasklet_schedule 的 实现 : 


static inline void tasklet_schedule(struct tasklet_struct *t) 


{ 
if (!test_and_set_bit(TASKLET_STATE_SCHED, &t->state)) 

__tasklet_schedule(t); 

} 

void __tasklet_schedule(struct tasklet_struct *t) 

{ 
unsigned long flags; 
local_irq_save(flags); 
t->next = NULL; 
*__this_cpu_read(tasklet_vec.tail) = t; 
__this_cpu_write(tasklet_vec.tail, &(t->next)); 
raise_softirq_irgqoff(TASKLET_SOFTIRQ); 
local_irq_restore(flags); 

} 


我 们 看 到 它 检 测 并 设置 所 给 的 tasklet A TASKLET_STATE_SCHED 状态 ， 然 后 以 所 给 tasklet 为 参 
数 执行 了 _ tasklet_schedule 函数 。 _ tasklet_schedule 看 起 来 和 前 面 见 到 的 
raise_softirq 很 像 。 一 开始 它 保存 中 断 标志 并 禁用 中 断 ， 继 而 将 新 的 tasklet 添加 到 
tasklet_vec ， 然 后 调用 了 我 们 前 面 见 过 的 raise_softirq_irqoff 函数 。 当 Linux 内 核 调度 
器 决定 去 运行 一 个 延 后 函数 ， tasklet_action 函数 会 被 作为 和 TASKLET_SOFTIRQ 相关 联 的 延 
后 函数 调用 。 同 样 的 ， tasklet_hi action 会 被 作为 和 HI_soFTIRQ 相关 联 的 延 后 函数 调用 。 
这 些 函 数 之 所 以 如 此 相似 是 因为 他 们 之 间 只 有 一 个 地 方 不 同 --- tasklet_action 使 用 


tasklet_vec 而 tasklet_hi_action 使 用 tasklet_hi_vec ° 


让 我 们 看 下 tasklet_action žig LM: 


static void tasklet_action(struct softirq_action wa) 

{ 
local_irq_disable(); 
list = __this_cpu_read(tasklet_vec.head); 
__this_cpu_write(tasklet_vec.head, NULL); 
__this_cpu_write(tasklet_vec.tail, this_cpu_ptr(&tasklet_vec.head) ); 
local_irq_enable(); 


while (list) { 
if (tasklet_trylock(t)) { 
t->func(t->data); 
tasklet_unlock(t); 


在 tasklet_action 开始 时 利用 local irq disable 宏 禁 用 了 当前 处 理 器 的 中 断 ( 你 可 以 阅读 
本 书 第 二 部 分 了 解 更 多 关于 此 宏 的 信息 )。 接 下 来 获取 到 当前 处 理 器 对 应 的 普通 优先 级 tasklet 
列表 并 把 它 设 置 为 NULL ， 这 是 因为 所 有 的 tasklet 都 将 被 执行 。 然 后 使 能 当前 处 理 器 的 中 
断 ， 循 环 遍 历 tasklet 列表 ， 每 一 次 遍历 都 会 对 当前 tasklet 调用 tasklet_trylock 函数 来 更 
新 它 的 状态 为 TASKLET_STATE_RUN 


static inline int tasklet_trylock(struct tasklet_struct *t) 


{ 
return !test_and_set_bit(TASKLET_STATE_RUN, &(t)->state); 


} 


如 果 这 个 操作 成 功 了 就 会 执行 此 tasklet 的 处 理 函 数 (我 们 在 ”tasklet_init 中 所 设置 的 )， 然 


后 调用 tasklet_unlock 函数 清除 他 的 TASKLET_STATE_RUN 状态 。 


通常 情况 下 ， 这 就 是 tasklet 的 所 有 概念 。 当 然 这 些 还 不 足以 覆盖 所 有 的 tasklets ， 但 是 
我 想 大 家 可 以 以 此 为 切入 点 继续 学 习 下 去 。 


tasklets 在 Linux 内 核 中 是 一 个 广 泛 使 用 的 概念 2 但 就 像 我 在 本 章 开 头 所 写 的 ， 还 有 第 三 个 
延 后 中 断 机 制 -- 工作 队列 。 接 下 来 我 们 将 会 看 看 它 又 是 怎样 一 种 机 制 。 


工作 队列 


工作 队列 是 另外 一 个 处 理 延 后 函数 的 概念 ， 它 大 体 上 和 tasklets 类 似 。 工 作 队 列 运行 于 内 

核 进程 上 下 文 ， 而 tasklets 运 ee 这 意味 着 工作 队列 BARE tasklets 

一 样 必须 是 原子 性 的 。Tasklets 总 是 运行 于 它 提交 自 的 那个 处 理 器 ， 工 作 队 列 在 默认 情况 下 也 
是 这样 。 工作 队列 在 Linux 内 核 代码 kernel/workqueue.c 中 由 如 下 的 数据 结构 表示 : 


struct worker_pool { 


spinlock_t lock; 

int cpu; 

int node; 

int id; 
unsigned int flags; 
struct list_head worklist; 
int nr_workers; 


因为 这 个 结构 有 非常 多 的 成 员 ， 这 里 就 不 把 它们 全 部 罗列 出 来 ， 下 面 只 讨论 上 面 列 出 的 这 


l o 


工作 队列 最 基础 的 用 法 ， 是 作为 创建 内 核 线 程 的 接口 来 处 理 提交 到 队列 里 的 工作 任务 。 所 有 
这 些 内 核 线程 称 之 为 worker thread 。 工 作 队 列 内 的 任务 是 由 代码 include/linux/workqueue.h 
中 定义 的 work_struct 表示 的 ， 起 定义 如 下 : 


struct work_struct { 
atomic_long_t data; 
struct list_head entry; 
work_func_t func; 
#ifdef CONFIG_LOCKDEP 
struct lockdep_map lockdep_map; 
#endif 
}; 


这 里 有 两 个 字段 比较 有 意思 : func -- 将 被 工作 队列 调度 执行 的 函数 ， data -- 这 个 函数 的 参 
数 。Linux 内 核 提 供 了 称 之 为 kworker 的 特定 于 每 个 cpu 的 内 核 线程 : 


systemd-cgls -k | grep kworker 
5 [kworker/0:0H] 
15 [kworker/1:0H] 
[kworker/2:0H] 
25 [kworker/3:0H] 
30 [kworker/4:0H] 


TTET 
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这 些 线程 会 被 用 来 调度 执行 工作 队列 的 延 后 函数 (就 像 ksoftirqd 之 于 坎 中 断 )。 除 此 之 外 我 
们 还 可 以 为 一 个 工作 队列 创建 一 个 新 的 工作 线程 。Linux 内 核 提 供 了 如 下 宏 静 态 创建 一 个 队列 
任务 : 


#define DECLARE_WORK(n, f) \ 
struct work_struct n = __WORK_INITIALIZER(n, f) 


它 需要 两 个 参数 : 工作 队列 的 名 字 和 工作 队列 的 函数 。 我 们 还 可 以 在 运行 时 动态 创建 : 


#define INIT WORK(_work, _func) \ 
INIT_WORK((_work), (_func), 0) 








#define INIT_WORK(_work, _func, _onstack) 
do { 





init_work((_work), _onstack); 
(_work)->data = (atomic_long_t) WORK_DATA_INIT(); 
INIT_LIST_HEAD(&(_work)->entry); 
(_work)->func = (_func); 
} while (0) 





a ee 


这 个 宏 需 要 一 个 work_struct 数据 结构 作为 将 要 创建 的 队列 任务 ， 和 一 个 将 在 这 个 任务 里 调 
度 运 行 的 函数 。 通 过 这 两 个 宏 的 其 中 一 个 创建 一 个 work 后 ， 我 们 需要 把 它 放 到 工作 队列 中 
去 。 可 以 通过 queue_work 或 者 queue_delayed_work 来 做 到 这 一 点 : 


static inline bool queue_work(struct workqueue_struct *wq, 
struct work_struct *work) 


return queue_work_on(WORK_CPU_UNBOUND, wq, work); 


queue_work 只 是 调用 了 queue_work_on KAR xe FA AOA o EMRE 

queue_work_on 函数 传递 了 woRK_cPU_UNBOUND 参数 ， 它 作为 代表 队列 任务 要 绑 定 到 哪 一 个 处 
理 器 的 枚 举 一 员 ， 定 义 于 include/linux/workqueue.h ° queue_work_on 函数 测试 并 设置 所 

给 任务 的 WORK_STRUCT_PENDING_BIT 标志 位 ， 然 后 以 所 给 的 工作 队列 和 队列 任务 为 参数 执行 


_ queue work 函数 : 


bool queue_work_on(int cpu, struct workqueue_struct *wq, 
struct work_struct *work) 


{ 
bool ret = false; 
if (!test_and_set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work))) { 
_ queue_work(cpu, wq, work); 
ret = true; 
} 
return ret; 
} 


__queue_work 函数 得 到 参数 work poll ° 是 的 ， 是 work poll 而 不 是 workqueue ° 实际 
上 ， 所 有 的 works 都 没有 放 在 workqueue 中 ， 而 是 放 在 Linux 内 核 中 由 worker_pool 数据 
结构 所 定义 的 work poll ° 如 上 所 述 ， workqueue_struct 数据 结构 的 pwqs 成 员 是 一 个 
worker_pool 列表 。 当 我 们 创建 一 个 workqueue ， 他 针对 每 一 个 处 理 器 都 创建 了 

worker_pool ° 每 一 个 和 worker_pool 相关 联 的 pool_workqueue 都 分 配 在 相同 的 处 理 器 上 
对 应 的 优先 级 队列 ” workqueue 通过 他 们 和 worker_pool 交互 。 在 __queue_work 函数 里 使 
用 raw_smp_processor_id 设置 Cpu 为 当 前 处 理 器 在 第 四 章 你 可 以 找到 更 多 相 关 信 息 ) » 得 到 与 
所 给 work_struct 对 应 的 pool_workqueue 并 将 work 插入 到 workqueue 


static void __queue_work(int cpu, struct workqueue_struct *wq, 
struct work_struct *work) 


{ 


if (req_cpu == WORK_CPU_UNBOUND ) 
cpu = raw_smp_processor_id(); 


if (!(wq->flags & WQ_UNBOUND) ) 
pwq = per_cpu_ptr(wq->cpu_pwqs, cpu); 
else 
pwq = unbound_pwq_by_node(wq, cpu_to_node(cpu) ); 


insert_work(pwq, work, worklist, work_flags); 


现在 我 们 可 以 创建 works 和 workqueue ， 我 们 需要 知道 他 们 究竟 会 在 何 时 被 执行 。 就 像 前 面 
提 到 的 ， 所 有 的 works 都 会 在 内 核 线程 中 执行 。 当 内 核 线程 得 到 调度 ， 它 开始 执行 
workqueue 中 的 works ° 每 一 个 工作 队列 内 核 线程 都 会 在 worker_thread 函数 里 执行 一 个 循 
环 。 这 些 内 核 线程 会 做 很 多 不 同 的 事情 ， 其 中 一 些 和 本 章 前 面 提 到 的 很 类 似 。 当 开始 执行 

时 ， 所 有 的 work_struct 和 works 都 会 从 他 的 workqueue 移 除 。 


总 结 


im 
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现在 结束 了 中 断 和 中 断 处 理 的 第 九 节 。 这 一 节 中 我 们 继续 讨论 了 外 部 硬件 中 断 。 在 之 前 部 分 

我 们 看 到 了 IRQs 的 初始 化 和 irq_desc 数据 结构 ， 在 这 一 节 我 们 看 到 了 用 于 延 后 函数 的 三 

个 概念 : 软 中 断 ， tasklet 和 工作 队列 © 

下 一 节 将 是 中 断 和 中 断 处 理 的 最 后 一 节 。 我 们 将 会 了 解 监 正 的 硬件 驱动 ， 并 试 着 学 习 它 是 怎样 
和 中 断 子 系 统一 起 工作 的 。 

如 果 你 有 任何 问题 或 建议 ， 请 给 我 发 评论 或 者 给 我 发 Twitter 。 


请 注意 美语 并 不 是 我 的 母语 ， 我 为 任何 表达 不 清楚 的 地 方 感到 抱歉 。 如 果 你 发 现任 何 错 误 请 
发 PR 到 linux-insides。( 译 者 注 : 翻译 问题 请 发 PR 到 linux-insides-cn) 
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中 断 和 中 断 处 理 (十 ) 


本 文 是 Linux 内 核 中 断 和 中 断 处 理 的 第 十 节 。 在 上 一 节 ， 我 们 了 解 了 延 后 中 断 及 其 相关 概 
念 ， 如 softirq ， tasklet ， workqueue 。 本 节 我 们 继续 深入 这 个 主题 > 现在 是 见识 在 正 的 
硬件 驱动 的 时 候 了 。 


以 StringARM** SA-100/21285 评估 板 串 行 驱动 为 例 ， 我 们 来 观察 驱动 程序 如 何 请 求 一 个 IRQ 
线 ， 一 个 中 断 被 触发 时 会 发 生 什 么 之 类 的 。 了 驱动 程序 代码 位 于 drivers/tty/serial/21285.c MX 
件 。 好 啦 ， 源 码 在 手 ， 说 走 就 走 ! 


一 个 内 核 模 块 的 初始 化 


与 本 书 其 他 新 概念 类 似 ， 为 了 考察 这 个 驱动 程序 ， 我 们 从 考察 它 的 初始 化 过 程 开 始 。 如 你 所 
Fa > Linux 内 核 为 驱动 程序 或 者 内 核 模块 的 初始 化 和 终止 提供 了 两 个 宏 : 


© module_init 


© module exit 


可 以 在 驱动 程序 的 源 代码 中 查阅 这 些 宏 的 用 法 : 


module_init(serial21285_init); 
module_exit(serial21285_exit); 


大 多 数 驱 动 程序 都 能 编译 成 一 个 可 装载 的 内 核 模 块 ， 亦 或 被 静态 地 链 入 Linux ave, 。 前 一 种 
情况 下 ， 一 个 设备 驱动 程序 的 初始 化 由 module_ init 与 module exit 宏 触 发 。 这 些 宏 定义 在 
include/linux/init.h 中 : 


#define module_init(initfn) À 
static inline initcall_t __inittest(void) \ 
{ return initfn; } N 


int init_module(void) __attribute__((alias(#initfn) )); 


#define module_exit(exitfn) \ 
static inline exitcall_t __exittest(void) N 
{ return exitfn; } \ 


void cleanup_module(void) _ attribute ((alias(#exitfn))); 


并 被 initcall 函数 调用 : 


© early_initcall 

@ pure_initcall 

® core_initcall 

@ postcore_initcall 
e arch_initcall 

e subsys_initcall 

e fs_initcall 

e rootfs_initcall 


@ device_initcall 


late_initcall 


He hy He LAK init/main.c 中 的 do initcalls 函数 调用 。 然 而 ， 如 果 设 备 驱 动 程序 被 静态 链 入 
Linux 内 核 ， 那 么 这 些 宏 的 实现 则 如 下 所 示 : 


#define module_init(x) __initcall(x); 
#define module_exit(x) __exitcall(x); 


这 种 情况 下 ， 模 块 装载 的 实现 位 于 kernel/module.c 源 文件 中 ， 而 初始 化 发 生 在 
do_init_module BAA o 我 们 不 打算 在 本 章 深 入 探讨 可 装 载 模 块 的 细 枝 末节 ， 而 会 在 一 个 专 
门 介绍 Linux ARR SP BHR o ea > module init 宏 接 受 一 个 参数 - 本 例 
PEMER serial21285_init 。 从 元 数 名 可 以 得 知 ， 这 个 函数 做 了 一 些 驱 动 程序 初始 化 的 相 
关 工 作 。 请 看 : 


static int __init serial21285_ init(void) 


{ 
int ret; 
printk(KERN_INFO "Serial: 21285 driver\n"); 
serial21285_setup_ports(); 
ret = uart_register_driver(&serial21285_reg); 
if (ret == 0) 
uart_add_one_port(&serial21285_reg, &serial21285_port); 
return ret; 
} 


如 你 所 见 ， 首 先 它 把 驱动 程序 相关 信息 写 入 内 核 缓 冲 区 ， 然 后 调用 serial21285_setup_ports 
函数 。 该 函数 设置 了 serial21285_port 设备 的 基本 uart 时 钟 : 


unsigned int mem_fclk_21285 = 50000000; 


static void serial21285 setup_ports(void) 


{ 
serial21285_port.uartclk = mem_fclk_21285 / 4; 


此 处 的 serial21285 是 描述 uart 驱动 程序 的 结构 体 : 


static struct uart_driver serial21285_reg = { 


. owner = THIS_MODULE, 
.driver_name = "ttyFB", 

.dev_name = "ttyFB", 

.major = SERIAL_21285 MAJOR, 
.minor = SERIAL_21285 MINOR, 
.nr = 1, 

.cons = SERIAL_21285 CONSOLE, 


}; 


如 果 驱 动 程序 注册 成 功 ， 我 们 借助 drivers/tty/serial/serial_core.c 源 文件 中 的 
uart_add_one_port 区 数 添加 由 驱动 程序 定义 的 端口 serial21285_port 结构 体 ， 然 后 从 
serial21285_init SARE: 


if (ret == 0) 
uart_add_one_port(&serial21285_ reg, &serial21285_ port); 


return ret; 


到 此 为 止 ， 我 们 的 驱动 程序 初始 化 完毕 。 当 一 个 uart 3% 0 *K drivers/tty/serial/serial_core.c 
中 的 uart_open 元 数 打 开 ， 该 函数 会 调用 uart_startup 函数 来 启动 这 个 串 行 端口 ， 后 者 会 
调用 startup 函数 。 它 是 uart_ops 结构 体 的 一 部 分 。 每 个 uart 驱动 程序 都 会 定义 这 样 一 
个 结构 体 。 在 本 例 中 ， 它 是 这 样 的 : 


static struct uart_ops serial21285_ops = { 


.startup = serial21285_startup, 


可 以 看 到 ， startup 字段 是 对 serial21285_startup Maas] Ao KP MA KM CMAN 
关注 重点 ， 因 为 它 与 中 断 和 中 断 处 理 密 切 相关 。 


请 求 中 断 线 


我 们 来 看 看 serial21285_startup 函数 的 实现 : 


static int serial21285 startup(struct uart port *port) 


{ 


int ret; 


tx_enabled(port) = 1; 
rx_enabled(port) = 1; 


ret = request_irq(IRQ_CONRX, serial21285_rx_chars, 0, 
serial21285_name, port); 
if (ret == 0) { 
ret = request_irgq(IRQ_CONTX, serial21285_tx_chars, 0, 
serial21285_name, port); 
if (ret) 
free_irgq(IRQ_CONRX, port); 


recunn ret, 


首先 是 Tx 和 RX 。 一 个 设备 的 串 行 总 线 仅 由 两 条 线 组 成 : 一 条 用 于 发 送 数据 ， 另 一 条 用 于 接 
收 数 据 。 与 此 对 应 ， 串 行 设备 应 该 有 两 个 串 行 引 脚 : 接收 器 - RX 和 发 送 器 - x 。 通 过 调用 
tx_enabled 和 rx_enalbed 这 两 个 宏 来 激活 这 些 线 。 函 数 接 下 来 的 部 分 是 我 们 最 感 兴趣 的 。 
注意 request_irq 这 个 函数 。 它 注册 了 一 个 中 断 处 理 程序 ， 然 后 激活 一 条 给 定 的 中 断 线 。 看 
一 下 这 个 函数 的 实现 细节 。 该 函数 定义 在 include/linux/interrupt.h 头 文件 中 ， 如 下 所 示 : 


static inline ant) — must check 
request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags, 
const char *name, void *dev) 


return request_threaded_irq(irq, handler, NULL, flags, name, dev); 


可 以 看 到 ， request_irq 函数 接受 五 个 参数 : 


e irq- 被 请 求 的 中 断 号 

e handler - 中断 处 理 程序 指针 
e flags - 掩 码 选项 

© name - 中 断 拥有 者 的 名 称 

© dev - 用 于 共享 中 断 线 的 指针 


现在 我 们 来 考察 request_irq 函数 的 调用 。 可 以 看 到 ， 第 一 个 参数 是 IRQ CONRX 。 我 们 知道 
它 是 中 断 号 ， 但 cONRX 又 是 什么 东西 ?这 个 宏 定义 在 arch/arm/mach- 
footbridge/include/mach/irgs.h 头 文 件 中 。 我 们 可 以 在 这 里 找到 21285 主板 能 够 产生 的 全 部 


中 断 。 注 意 ， 在 第 二 次 调用 request irg 函数 时 ， 我 们 传 入 了 IRQ coNTX 中 断 号 。 我 们 的 驱 
动 程序 会 在 这 些 中 断 中 处 理 Rx 和 Tx 事件 。 这 些 宏 的 实现 很 简单 : 


#define IRQ_CONRX _DC21285_IRQ(0) 
#define IRQ_CONTX _DC21285_IRQ(1) 
#define _DC21285_IRQ(x) (16 + (x)) 


这 个 主板 的 ISA 中 断 号 分 布 在 6 到 15 这 个 范围 内 。 因 此 ， 我 们 的 中 断 号 就 是 在 此 之 后 的 头 
两 个 值 : 16 和 17 ° HE request_irq 函数 的 两 次 调用 中 ， 第 二 个 参数 分 别 是 
serial21285_rx_chars 和 serial21285_tx_chars 函数 。 当 一 个 rx 或 TX 中 断 发 生 时 ， 这 
些 函 数 就 会 被 调用 。 我 们 不 会 在 此 深入 探究 这 些 函 数 ， 因 为 本 章 讲述 的 是 中 断 与 中 断 处 理 ， 
而 并 非 设 备 和 驱动 。 下 一 个 参数 是 flags ? request_irq 函数 的 两 次 调用 中 它 的 值 都 是 
Ro PA SKA flags 都 在 include/linux/interrupt.h 中 定义 成 诸如 IRQF_* 此 类 的 宏 。 一 些 
例子 : 


© IRQF_SHARED - 允许 多 个 设备 共享 此 中 断 号 

© IRQF_PERCPU - 此 中 断 号 属于 单独 cpu 的 (per cpu) 
© IRQF_NO_THREAD - 中断 不 能 线程 化 

© IRQF_NOBALANCING - 此 中 断 步 参与 irq 平 衡 时 

e IRQF_IRQPOLL - 此 中 断 用 于 轮 询 


KE KE 


。 等 等 


这 里 ， 我 们 传 入 的 是 o ， 也 就 是 IRQF_TRIGGER_NONE 。 这 个 标志 是 说 ， 它 不 配置 任何 水 平 触 
发 或 边缘 触发 的 中 断 行 为 。 至 于 第 四 个 参数 ( name )， 我 们 传 入 serial21285_name ， 它 定义 
如 下 : 


static const char serial21285_name[] = "Footbridge UART"; 


它 会 显示 在 /proc/interrupts 的 输出 中 。 针 对 最 后 一 个 参数 ， 我 们 传 入 一 个 指向 uart_port 
结构 体 的 指针 。 对 request_irq 函数 及 其 参数 有 所 了 解 后 ， 我 们 来 看 看 它 的 实现 。 从 上 文 可 
知 ， request_irq 函数 内 部 只 是 调用 了 定义 在 kernel/irq/manage.c 源 文件 中 的 

request_threaded_irgq 函数 ， 并 分 配 了 一 个 给 定 的 中 断 线 °K 函数 起 始 部 分 是 irqaction 和 


irq_desc 的 定义 : 


int request_threaded_irq(unsigned int irq, irq_handler_t handler, 
irq_handler_t thread_fn, unsigned long irgflags, 
const char *devname, void *dev_id) 


{ 
struct irqaction *action; 
struct irq_desc *desc; 
int retval; 

} 


在 本 章 ， 我 们 已 经 见识 过 irgaction 和 irq_desc 结构 体 了 。 第 一 个 结构 体 表示 一 个 中 断 动 
作 描 述 符 ， 它 包含 中 断 处 理 程序 指针 ， 设 备 名 称 ， 中 断 号 等 等 。 第 二 个 结构 体 表示 一 个 中 断 
首 述 符 ， 和 包含 指向 irqaction 的 指针 ， 中 断 标志 等 等 。 注意 ， request_threaded_irq 函数 被 
request_irq 调用 时 ， 带 了 一 个 额 外 的 参数 > irgq_handler_t thread_fn ° 如 果 这 个 参数 不 为 
NULL ， 它 会 创建 irq 线程 ， 并 在 该 线程 中 执行 给 定 的 irq 处 理 程序 。 下 一 步 ， 我 们 要 做 
如 下 检查 : 


if (((irqflags & IRQF_SHARED) && !dev_id) || 
(!(irqflags & IRQF_SHARED) && (irqflags & IRQF_COND_SUSPEND)) || 
((irqflags & IRQF_NO_SUSPEND) && (irqflags & IRQF_COND_SUSPEND) )) 
return -EINVAL; 


BA? RIN ARAS PHN IGAT BEA dev_id ( 译 者 注 : eda 
了 中 断 )， 而 且 IRQF_COND_SUSPEND 仅 对 共享 中 断 生效 。 否 则 退出 函数 ， -EINVAL 错 
误 。 之 后 ， 我 们 借助 kernel/irq/irqdesc.c 源 文件 中 定义 的 irq_to_desc Pi 给 定 的 irg 
中 断 号 转换 成 irq 中 断 描 述 符 。 如 果 不 成 功 ， 则 退出 函数 ， 返 回 -EINVAL 错误 : 


desc = irq_to_desc(irq); 
if (!desc) 
return -EINVAL; 


irgq_to_desc HIE 给 定 的 irq 中 断 号 是 否 小 于 最 大 中 断 号 2 并 且 返 回 中 断 描述 符 。 这 
里 ，irq 中 断 号 就 是 irq_desc 数组 的 偏 移 量 : 


struct irq desc *irq_to_desc(unsigned int irq) 


{ 
return (irq < NR_IRQS) ? irq desc + irq : NULL; 


由 于 我 们 已 经 把 irq 中 断 号 转换 成 了 irg 中 断 描述 符 ， 现 在 来 检查 描述 符 的 状态 ， 确 保 我 
们 可 以 请 求 中 断 : 


if (!irq_settings_can_request(desc) || WARN_ON(irq_settings_is_per_cpu_devid(desc) ) ) 
return -EINVAL; 


失败 则 返回 -EINVAL 错误 。 接 着 ， 我 们 检查 给 定 的 中 断 处 理 程序 ( 译 者 注 : 是 指 handler 变 
量 ) o 如果 它 没 被 传 入 request_irq Až > RME thread fn ° 两 个 都 是 NULL 则 返回 
-EINVAL 。 如 果 中 断 处 理 程序 没有 被 传 入 request_irq 函数 而 thread fn 不 为 室 ， 则 把 


handler 设 为 irg_default_primary_handler 


if (!handler) { 
if (!thread_fn) 
return -EINVAL; 
handler = irg_default_primary_handler; 


下 一 步 ， 我 们 通过 kzalloc BAA irgaction 分 配 内 存 ， 若 不 成 功 则 返回 


action = kzalloc(sizeof(struct irqaction), GFP_KERNEL); 
if (!action) 
return -ENOMEM; 


Akke kzalloc 详情 ， 请 查阅 专门 介绍 Linux 内 核 内 存 管理 的 章节 。 为 irqaction 分 配 空间 
后 ， 我 们 即 对 这 个 结构 体 进 行 初 始 化 ， 设 置 它 的 中 断 处 理 程序 ， 中 断 标志 ， 设 备 名 称 等 等 


action->handler = handler; 
action->thread_fn = thread_fn; 
action->flags = irqflags; 
action->name = devname; 


action->dev_id = dev_id; 


在 request_threaded_irq MAA» AMAA kernel/irq/manage.c 中 的 _setup_irq & 
数 ， 并 注册 一 个 给 定 的 irqaction 。 然 后 释放 irgaction 内 存 并 返回 


chip_bus_lock(desc); 
retval = __setup_irq(irg, desc, action); 
chip_bus_sync_unlock(desc) ; 


if (retval) 
kfree(action); 


return retval; 


注意 ” __setup_irgq 函数 的 调用 位 于 chip_bus_lock 和 chip_bus_sync_unlock HAZ lal o à 
函数 对 慢 速 总 线 ( 如 i2c) 芯 片 进行 锁定 了 解锁。 现在 来 看 看 setup irg 函数 的 实 

e __setup_irg 函数 开头 是 各 种 检查 。 首 先 我 们 检查 给 定 的 中 断 描 述 符 不 为 

NULL ， irqchip 不 为 NULL ， 以 及 给 定 的 中 断 描述 符 模块 拥有 者 不 为 NULL 。 接 下 来 我 们 
检查 中 断 是 否 诅 套 在 其 他 中 断 线程 中 。 如 果 是 的 ， 我 们 则 以 irq_nested_primary_handler aR 
换 irg_default_priamry_handler ° 


eve 


下 一 步 ， wRAC PRERA > HA thread fn TA È > RAM 
kthread_create 创建 了 一 个 中 断 处 理 线程 。 


If (new->thread_fn && !nested) { 
struct task_struct *t; 
t = kthread_create(irg_thread, new, "“irg/%d-%s", irq, new->name); 


并 在 最 后 为 给 定 的 中 断 描 述 符 的 剩余 字段 赋值 。 于 是 ， 我 们 的 16 和 17 号 中 断 请 求 线 注册 
完毕 。 当 一 个 中 断 控制 器 获得 这 些 中 断 的 相关 事件 时 ， serial21285_rx_chars 

和 serial21285_tx_chars 函数 会 被 调用 。 现 在 我 们 来 看 一 看 一 个 中 断 发 生 时 到 底 发 生 了 什 

ZA o 


准备 处 理 中 断 


通过 上 文 ， 我 们 观察 了 为 给 定 的 中 断 描述 符 请 求 中 断 号 ， 为 给 定 的 中 断 注 册 irqaction 结构 
体 的 过 程 。 我 们 已 经 知道 ， 当 一 个 中 断 事件 发 生 时 ， 中 断 控制 器 向 处 理 器 通知 该 事件 ， 处 理 
器 尝试 为 这 个 中 断 找 到 一 个 ee 
native_init_IRQ 远 数 。 这 个 函数 会 初始 化 本 地 APIC。 这 个 函数 的 如 下 部 分 是 我 们 现在 最 
兴趣 的 地 方 : 


for_each_clear_bit_from(i, used_vectors, first_system_vector) { 





set_intr_gate(i, irq_entries_start + 
8 * (i - FIRST_EXTERNAL_VECTOR) ); 


这 里 ， 我 们 从 第 first_system vector 位 开始 ， 依 次 向 后 迭代 used vectors 位 图 中 所 有 被 清 
除 的 位 : 


int first_system_vector = FIRST_SYSTEM_VECTOR; // Oxef 


FARE POT] > i 是 向 量 号 ， irq_entries_start + 8 * (i - FIRST_EXTERNAL_VECTOR) 是 起 
始 地 址 。 仅 有 一 处 尚 不 明了 - irq_entries_start 。 这 个 符号 定义 在 
arch/x86/entry/entry_64.S 汇编 文件 中 ， 并 提供 了 irq 入 口 。 一 起 来 看 : 


.align 8 
ENTRY(irg_entries_start) 
vector=FIRST_EXTERNAL_VECTOR 
.rept (FIRST_SYSTEM_VECTOR - FIRST_EXTERNAL_VECTOR) 
pushq $(~vector+0x80) 
vector=vector+1 


jmp common_interrupt 
„align 8 
„endr 


END(irq_entries_start) 


这 里 我 们 可 以 看 到 GNU 汇编 器 的 .rept 指令 。 这 条 指令 会 把 .endr 之 前 的 这 几 行 代码 重 


复 FIRST_SYSTEM_VECTOR - FIRST_EXTERNAL_VECTOR 次 。 我 们 已 经 知道 FIRST_SYSTEM_VECTOR 的 


值 是 gxef ， 而 FIRST_EXTERNAL VECTOR 等 于 0x20 。 于 是 ， 它 将 运行 : 


>>> Oxef - 0x20 
207 


Ke fe .rept 指令 主体 中 ， 我 们 把 入 口 程序 地 址 压 入 栈 中 (注意 ， 我 们 使 用 负数 表示 中 断 向 
量 号 ， 因 为 正 数 留 作 标识 系统 调用 之 用 )， 将 vector 变量 加 1， 并 跳 转 到 common_interrupt 
标签 。 在 common_interrupt 中 ， 我 们 调整 了 栈 中 向 量 号 ， 执 行 interrupt 指令 ， 参 数 是 


do_IRQ 


common_interrupt: 
addq $-0x80, (%rsp) 
interrupt do_IRQ 


interrupt 宏 定义 在 同一 个 源 文件 中 。 它 把 通用 寄存 器 的 值 保 存在 栈 中 。 如 果 需 要 ， 它 还 会 
通过 swAPGS 汇编 指令 在 内 核 中 改变 用 户 空间 gs 寄存 器 。 它 会 增加 per-cpu 的 irq_count 
变量 ， 来 表明 我 们 处 于 中 断 状态 ， 然 后 调用 do_IRQ 函数 。 该 函数 定义 于 
arch/x86/kernel/irg.c 源 文件 中 ， 作 用 是 处 理 我 们 的 设备 中 断 。 让 我 们 一 起 考察 这 个 函 

数 。 do_IRQ 函数 接受 一 个 参数 - pt_regs 结构 体 ， 它 存放 着 用 户 空间 寄存 器 的 值 : 


__visible unsigned int __irg_entry do_IRQ(struct pt_regs *regs) 


{ 
struct pt_regs *old_regs = set _ irq _ regs(regs); 
unsigned vector = ~regs->orig_ax; 
unsigned irq; 
irq_enter(); 
exit_idle(); 
} 


函数 开头 调用 了 set_irq_regs 哆 数 ， 后 者 返回 被 保存 的 per-cpu 中 断 寄 存 器 指针 。 然 后 又 
调用 irg_enter 和 exit_idle 函数 。 第 一 个 函数 irg_enter 进入 到 一 个 中 断 上 下 文 ， 更 新 
_ preempt_count 变量 。 第 二 个 函数 exit_idle 检查 当前 进程 是 否 是 pid 为 o 的 idle 进 


程 ， 然 后 把 IDLE_END 传送 给 idle notifier ° 


接 下 来 ， 我 们 从 当前 cpu 中 读 取 irq 值 ， 并 调用 handle_irq BH: 


irq = __this_cpu_read(vector_irq[vector]); 


if (!handle_irq(irg, regs)) { 


handle_irq Až Æ 0 arch/x86/kernel/irq_64.c 源 文件 中 ， 它 检查 给 定 的 中 断 描述 符 ， 然 后 
调用 generic_handle_irq_desc 函数 : 


desc = irq_to_desc(irq); 
if (unlikely(!desc) ) 
return false; 
generic_handle_irgq_desc(irq, desc); 


该 函数 又 调用 中 断 处 理 程序 : 


static inline void generic_handle_irq_desc(unsigned int irq, struct irq_desc *desc) 


{ 


desc->handle_irq(irg, desc); 


但 是 ， 停 一 停 een handle_irg 是 何方 神圣 ， 为 什么 在 知道 irqaction 48 1) LAE hg P Bp ab EE 
程序 的 情况 下 ， 偏 偏 通 过 中 断 描述 符 调 用 我 们 的 中 断 处 理 程 序 ? 实际 上 > irq_desc- 
>handle_irq paa o 中 断 处 理 程序 的 上 层 APl。 它 在 设备 树 和 APIC 的 初始 化 过 程 中 
就 设 定好 了 。 内 核 通 择 正 确 的 函数 以 及 irq->actions(s) 的 调用 链 。 就 这 样 ， 当 一 个 
中 断 发 生 时 ， serial21285_tx_chars 或 者 serial21285_rx_chars 函数 会 被 调用 。 


在 do IR HAKE’ AMAA irq exit 函数 来 退出 中 断 上 下 文 ， 调 用 set irq regs % 
数 并 传 入 先前 的 用 户 空间 寄存 器 ， 最 后 返回 


irq_exit(); 
set_irq_regs(old_regs); 
return, 4; 


我 们 已 经 知道 ， 当 一 个 IRQ 工作 结束 之 后 ， 如 果 有 延 后 中 断 ， 它 们 会 被 执行 。 


退出 中 断 


好 了 ， 中 断 处 理 程序 执行 完毕 ， 我 们 必须 从 中 断 中 返回 。 在 dorr 函数 将 工作 处 理 完毕 
后 ， 我 们 将 回 到 arch/x86/entry/entry_64.S 汇编 代码 的 ret_from_intr 标签 处 。 首 先 ， 我 们 
通过 DISABLE_INTERRUPTS 宏 禁 止 中 断 ， 这 个 宏 被 扩展 成 cli 指令 ， 将 per-cpu 的 


irq_count 变量 值 减 1。 记 住 ， 当 我 们 处 于 中 断 上 下 文 的 时 候 ， 这 个 变量 的 值 是 1 : 


DISABLE_INTERRUPTS(CLBR_NONE) 
TRACE_IRQS_OFF 
decl PER_CPU_VAR(irg_count) 


最 后 一 步 ， 我 们 检查 之 前 的 上 下 文 (用 户 空间 或 者 内 核 空间 )， 正 确 地 恢复 它 ， 然 后 通过 指令 退 
hes 


INTERRUPT_RETURN 


此 处 的 INTERRUPT_RETURN ZÆ : 


#define INTERRUPT_RETURN jmp native_iret 


ENTRY(native_iret) 


.global native_irg_return_iret 
native_irq_return_iret: 
iretq 


本 节 到 此 结束 。 


总 结 


Ed 


4 


这 里 是 中 断 和 中 断 处理 章节 的 第 十 节 的 结尾 。 如 你 在 本 节 开 头 读 到 的 那样 ， 这 是 本 章 的 最 后 
一 节 。 本 章 开 篇 益 述 了 中 断 理论 ， 我 们 于 是 明白 了 什么 是 中 断 ， 中 断 的 类 型 ， 然 后 也 了 解 了 
异常 以 及 对 这 种 类 型 中 断 的 处 理 ， 延 后 中 断 。 最 后 在 本 节 ， 我 们 考察 了 硬件 中 断 和 对 这 些 中 
断 的 处 理 。 当 然 ， 本 节 甚 至 本 章 都 未 能 履 盖 到 Linux 内 核 中 断 和 中 断 处理 的 所 有 方面 。 这 样 
并 不 现实 ， 至 少 对 我 而 言 如 此 。 这 是 一 项 浩大 工程 ， 不 知 你 作 何 感想 ， 对 我 来 说 ， 它 确实 浩 
大 。 这 个 主题 远 远 超出 本 章 讲述 的 内 容 ， 我 不 确定 地 球 上 能 否 找 到 一 本 书 可 以 涵盖 这 个 主 
题 。 我 们 漏 掉 了 关于 中 断 和 中 断 处 理 的 很 多 内 容 ， 但 我 相信 ， 深 入 研究 中 断 和 中 断 处 理 相 关 
的 内 核 源 码 是 个 不 错 的 点 子 。 


如 果 有 任何 疑问 或 者 建议 ， 撰 写 评论 或 者 在 twitter 上 联系 我 。 


请 注意 ， 英 语 并 非 我 的 母语 。 任 何不 便 之 处 ， 我 深 感 抱 菊 。 如 果 发 现任 何 错误 ， 请 在 linux- 
insides 向 我 发 送 PR。( 译 者 注 : 翻译 问题 请 发 送 PR 到 linux-insides-cn) 
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系统 调用 


本 章 描述 Linux 内 核 中 的 系统 调用 概念 。 


© 系统 调用 概念 简介 - 介绍 Linux 内 核 中 的 系统 调用 概念 

Linux 内 核 如 何 处 理 系 统 调 用 - 介绍 Linux 内 核 如 何 处 理 来 自 于 用 户 空 间 应 用 的 系统 调 
用 。 

e vsyscall and vDSO - 介绍 vsyscall 和 voso 概念 。 

© Linux 内 核 如 何 运行 程序 - 介绍 一 个 程序 的 启动 过 程 。 

open 系统 调用 的 实现 - 介绍 open 系统 调用 的 实现 。 

Linux 资源 限制 - 介绍 getrlimit/setrlimit 的 实现 。 


Linux 内 核 系统 调用 第 一 节 


简介 


这 次 提交 为 linux-insides 添加 一 个 新 的 章节 ， 从 标题 就 可 以 知道 , 这 一 章节 将 介绍 Linux AK 
中 System Call 的 概念 。 章 节 内 容 的 选择 并 非 偶然 。 在 前 一 章节 我 们 了 解 了 中 断 及 中 断 处 理 。 
系统 调用 的 概念 与 中 断 非 常 相 似 ， 这 是 因为 软件 中 断 是 执行 系统 调用 最 常见 的 方式 。 我 们 将 
讨论 系统 调用 概念 的 各 个 方面 。 例 如 ， 用 户 空 间 发 起 系统 调用 的 细节 ， 内 核 中 一 组 系统 调用 
处 理 器 的 执行 过 程 , VDSO 和 vsyscall 概念 以 及 其 他 信息 。 


在 了 解 Linux 内 核 系 统 调 用 执行 过 程 之 前 ， 了 解 一 些 系统 调用 的 原理 是 有 帮助 的 。 我 们 从 下 
面 的 段落 开始 。 


什么 是 系统 调用 ?3 


系统 调用 是 用 户 空间 请 求 内 核 服务 。 操 作 系 统 内 核 提 供 很 多 服务 。 当 程序 读 写 文件 ， 开 始 监 
听 连 接 的 Socket ， 删 除 或 创建 目录 或 程序 结束 时 ， 都 会 执行 系统 调用 。 换 句 话说 ， 系 统 调用 
仅仅 是 一 些 [C] (https://en.wikipedia.org/wiki/C_%28programming_language%29) 内 核 空间 
函数 ， 用 户 空 间 程序 调用 其 处 理 一 些 请 求 。 


Linux 内 核 提 供 一 系列 的 函数 并 且 这 些 函 数 与 CPU 架构 相关 。 例如 :x86 64 提供 322 个 系统 
调用 ，x86 提供 358 个 不 同 的 系统 调用 。 系统 调用 仅仅 是 一 些 函 数 。 我 们 讨论 一 个 使 用 汇编 
语言 编写 的 简单 Hello world 示例 : 


.data 


msg : 
„ascii "Hello, world!\n" 
len =. - msg 

.text 
.global _start 

_start: 


movq $1, %rax 
movq $1, %rdi 
movq $msg, %rsi 
movq $len, %rdx 
syscall 


movq $60, %rax 
xorq %rdi, %rdi 
syscall 


使 用 下 面 的 命令 可 编译 这 些 语句 : 


$ gcc -c test.S 
$ ld -o test test.o 


./test 
Hello, world! 


这 些 简 单 的 代码 是 一 个 简单 的 Linux x86_64 架构 Hello world 汇编 程序 ， 代 码 包 含 两 个 段 : 


e „data 


@ .text 


第 一 个 段 - .data 存储 程序 的 初始 数据 (在 示例 中 为 Hello world 字符 串 ). 第 二 个 段 - 

text 包含 程序 的 代码 . 程序 可 分 为 两 部 分 : 第 一 部 分 为 第 一 个 syscall 指令 之 前 的 代码 ， 
第 二 部 分 为 两 个 syscall 指令 之 间 的 代码 。 首 先 在 示例 程序 及 一 般 应 用 中 ， syscall 指令 
有 什么 功能 ?64-ia-32-architectures-software-developer-vol-2b-manual 中 提 到 : 


SYSCALL 引起 操作 系统 系统 调用 处 理 器 处 于 特权 级 09， 通过 加 载 IA32_LSTAR MSR 至 RIP 完 成 (在 RCX 中 保存 SYSCA 
LL 之 后 指令 地 址 之 后 )。 
(WRMSR 指令 确保 IA32_LSTAR MSR 总 是 包含 一 个 连续 的 地 址 。) 


SYSCALL 将 IA32_STAR MSR 的 47:32 位 加 载 至 CS 和 SS 段 选 择 器 。 

因此 ， 根 据 这些 段 选择 器 CS 和 SS ， 描 述 符 缓存 并 未 从 描述 符 加 载 (位 于 GDT 或 LDT 中 )。 相 反 ， 描 述 符 缓存 
从 固定 值 加 载 。 

操作 系统 软件 需要 确保 ， 由 段 选择 器 得 到 的 描述 符 与 从 固定 值 加 载 至 描述 符 缓存 的 描述 符 保持 一 致 。 SYSCALL 指令 
不 保证 两 者 的 一 致 。 


使 用 arch/x86/entry/entry_64.S 汇 编程 序 中 定义 的 entry_syscaLL_64 初始 化 syscalls 同时 
SYSCALL 指令 进入 arch/x86/kernel/cpu/common.c 源码 文件 中 的 IA32_sTAR Model specific 
register: 


wrmsrl(MSR_LSTAR, entry_SYSCALL 64); 


因此 ， syscall 指令 唤醒 一 个 系统 调用 对 应 的 处 理 程序 。 但 是 如 何 确定 调用 哪个 处 理 程序 ? 
事实 上 这 些 信 息 从 通用 目的 寄存 器 得 到 。 正 如 系统 调用 表 中 描述 ， 每 个 系统 调用 对 应 特定 的 
编号 。 上 面 的 示例 中 , 第 一 个 系统 调用 是 - write 将 数据 写 入 指定 文件 。 在 系统 调用 表 中 查找 
write 系统 调用 .write 系统 调用 的 编号 为 - 1 。 在 示例 中 通过 rax 寄存 器 传递 该 编号 ， 接 下 来 
的 几 个 通用 目 的 寄存 器 : %rdi , %rsi 和 %rdx 保存 write 系统 调用 的 参数 ° 在 示例 中 为 
文件 描述 符 (1 stdout), 第 二 个 参数 字符 串 指针 , 第 三 个 为 数据 的 大 小 。 是 的 ， 你 听 到 的 没 
错 ， 系 统 调用 的 参数 。 正 如 上 文 , 系统 调用 仅仅 是 内 核 空 间 的 c 函数 。 示 例 中 第 一 个 系统 调 
用 为 write > Æ [fs/read_write.c] 
(https://github.com/torvalds/linux/blob/master/fs/read_write.c) 源 文件 中 定义 如 下 : 


SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf, 
size_t, count) 


或 者 换言之 : 


ssize_t write(int fd, const void *buf, size_t nbytes); 


现在 不 用 担心 宏 SYSCALL_DEFINES , 稍 后 再 做 讨论 。 


示例 的 第 二 部 分 也 是 一 样 的 , 但 调用 了 另 一 系统 调用 exit。 这 个 系统 调用 仅 需 一 个 参数 : 


e Return value 


参数 说 明 程序 退出 的 方式 。sitrace 工具 可 根据 程序 的 名 称 输出 系统 调用 的 过 程 : 


$ strace test 

execve("./test", ["./test"], [/* 62 vars */]) = 0 
write(1, "Hello, world!\n", 14Hello, world! 

) = 14 

_exit(0) =? 


+++ exited with © +++ 


strace 输出 的 第 一 行 , execve 系统 调用 开始 执行 程序 ， 第 二 ， 三 行为 程序 中 使 用 的 系统 调 
用 : write 和 exit 。 注 意 示例 中 通过 通用 目的 寄存 器 传递 系统 调用 的 参数 。 寄 存 器 的 顺序 
是 特定 的 。 寄 存 器 的 顺序 由 - 声明 [x86-64 calling conventions] 
(https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions) 定 义 。 

x86_64 架构 的 声明 在 另 一 个 特别 的 文档 中 - System V Application Binary Interface. PDF 。 
通常 ,函数 参数 被 置 于 寄存 器 或 者 堆栈 中 。 正 确 的 顺序 为 : 


e rdi ; 
e prsae 
@ rdx; 
e (nex; 
e r8; 
e rg. 


对 应 函数 的 前 六 个 参数 。 若 函数 多 于 六 个 参数 ， 其 他 参数 将 放 在 堆栈 中 。 
示例 代码 中 未 直接 使 用 系统 调用 ， 但 程序 通过 系统 调用 打印 输出 ， 检 查 文件 的 权限 或 是 从 文 
件 中 读 写 。 


例如 : 


#include <stdio.h> 


int main(int argc, char **argv) 
{ 

FILE *fp; 

char buff[255]; 


fp = fonen( testotxe an) 
fgets(buff, 255, fp); 
printf("%s\n", buff); 
fclose(fp); 


return 0; 


Linux 内 核 中 没有 fopen ，fgets ，printf 和 fclose 系统 调用 ， 而 是 open, read write 
和 close ° fopen fgets, printf 和 fclose 仅仅 是 c standard library 中 定义 的 函数 。 
事实 上 这 些 函 数 是 系统 调用 的 封装 。 代 码 中 没有 直接 使 用 系统 调用 ， 而 是 通过 标准 库 的 封装 
函数 。 这 样 做 的 主要 原因 是 : 系统 调用 执行 的 要 快 ， 非 常 快 。 由 于 系统 调用 快 的 同时 也 非常 

小 。 标 准 库 在 执行 系统 调用 前 ， 确 保 系统 调用 参数 设置 正确 及 完成 其 他 不 同 的 检查 。 对 比 示 
例 程序 和 以 下 命令 : 


$ gcc test.c -o test 


通过 |trace 工 具 观 察 : 


$ ltrace ./test 

__libc_start_main([ "./test" ] <unfinished ...> 

fopen("test.txt", "r") 0x602010 
fgets("Hello World!\n", 255, 0x602010) = 0x7ffd2745e700 
puts("Hello World!\n"Hello World! 


) 14 
fclose(0x602010) = 0 
+++ exited (status 0) +++ 


ltrace 工具 显示 程序 用 户 空间 的 调用 。 fopen 函数 打开 给 定 的 文本 文件 ，fgets 函数 读 取 
文件 内 容 至 put 缓存 ， puts 输出 文件 内 容 至 stdout ， fclose 函数 根据 文件 描述 符 关 
闭 函 数 。 如 上 文 描述 ， 这 些 函 数 调 用 特定 的 系统 调用 。 例 如 : puts 内 部 调用 write 系统 
WA > ltrace 添加 -s 可 观察 到 这 一 调用 : 


write@SYS(1, "Hello World!\n\n", 14) = 14 


系统 调用 是 普遍 存在 的 。 每 个 程序 都 需要 打开 / 写 / 读 文件 ， 网 络 连 接 ， 内 存 分 配 和 许多 其 他 功 
能 只 能 由 内 核 完 成 。 proc 文件 系统 有 一 个 具有 特定 格式 的 特殊 文件 : /proc/pid/systemcall 16 
录 了 正在 被 进程 调用 的 系统 调用 的 编号 和 参数 寄存 器 。 例 如 ,进程 号 1 的 程序 是 systemd: 


$ sudo cat /proc/1/comm 
systemd 


$ sudo cat /proc/1/syscall 
232 0x4 Ox7ffdf82e11bO Oxif Oxffffffff 0x100 Ox7ffdf82e11bf 0x7ffdf82e11a0 Ox7f9114681 
193 


编号 为 - 232 的 系统 调用 为 epoll wait， 该 调用 等 待 epoll 文件 描述 符 的 MO 事件 . 例如 我 用 来 
编写 这 一 节 的 emacs 编辑 器 : 


$ ps ax | grep emacs 
2093 ? Sl 2:40 emacs 


$ sudo cat /proc/2093/comm 
emacs 


$ sudo cat /proc/2093/syscall 
270 Oxf 0x7fff068a5a90 Ox7FFFO68a5b10 OxO 0x7fff068a59c0 Ox7FFFO68a59d0 0x7fff068a59b0 
0x7f777dd8813c 
编号 为 270 的 系统 调用 是 sys_pselect6 ， 该 系统 调用 使 emacs 监控 多 个 文件 描述 符 。 


现在 我 们 对 系统 调用 有 所 了 解 ， 知 道 什 么 是 系统 调用 及 为 什么 需要 系统 调用 。 接 下 来 ， 讨 论 
示例 程序 中 使 用 的 write 系统 调用 


写 系 统 调用 的 实现 


查看 Linux 内 核 源 文件 中 写 系 统 调用 的 实现 。fs/read write.c 源码 文件 中 的 write 系统 调用 定 
义 如 下 : 


SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf, 
size_t, count) 


{ 
struct fd f = fdget_pos(fd); 
ssize_t ret = -EBADF; 
if (f.file) { 
loff_t pos = file_pos_read(f.file); 
ret = vfs_write(f.file, buf, count, &pos); 
if (ret >= 0) 
file_pos_write(f.file, pos); 
fdput_pos(f); 
} 
return ret; 
} 
首先 ， 宏 SYSCALL_DEFINE3 在 头 文件 include/linux/syscalls.h 中 定义 并 且 作 为 sys_name(...) 


~ 


函数 定义 的 扩展 。 宏 的 定义 如 下 : 


#define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, _ VA _ ARGS_ ) 
#define SYSCALL_DEFINEx(x, sname, ...) Ñ 
SYSCALL_METADATA(sname, x, __VA_ARGS__ ) \ 


__SYSCALL_DEFINEx(x, sname, _ VA ARGS ) 


宏 SYSCALL_DEFINES 的 参数 有 代表 系统 调用 的 名 称 的 name 和 可 变 个 数 的 参数 。 这 个 宏 仅 仅 
作为 syscALL_DEFINEx 宏 的 扩展 确定 了 传 入 宏 的 参数 个 数 。 _##name 作为 未 来 系统 调用 名 称 
的 存根 (更 多 关于 ae 符号 连结 可 参阅 documentation of gcc)。 宏 syYscALL_DEFINEx 作为 以 下 
两 个 宏 的 扩展 : 


@ SYSCALL METADATA 


@ __SYSCALL_DEFINEx 


第 一 个 宏 SyscALL_METADATA 的 实现 与 内 核 配 置 选 项 CONFIG_FTRACE_SYSCALLS 有 关 。 从 选项 
的 名 称 可 知 ， 选 项 允许 tracer 捕获 系统 调用 的 进入 和 退出 。 若 该 内 核 配 置 选 项 开启 ， 宏 
SYSCALL_METADATA 执行 头 文件 include/trace/syscall.h 中 syscall_metadata 结构 的 初始 化 。 结 

构 中 包含 多 种 有 用 字段 例如 系统 调用 的 名 称 , 系统 调用 表 中 的 编号 ， 参 数 个 数 , 参数 类 型 列表 


KE 


F: 


#define SYSCALL_METADATA(sname, nb, ...) \ 
\ 
\ 
\ 
struct syscall_metadata _ used \ 
__syscall_meta_##sname = { \ 
,name = "sys'"#sname, \ 
.syscall_nr = -1, N 
,nb_args = nb, \ 
. types = nb ? types_##sname : NULL, \ 
„args = nb ? args_##sname : NULL, \ 
.enter_event = &event_enter_##sname, \ 
.exit_event = &event_exit_##sname, \ 
.enter_fields = LIST_HEAD_INIT(__syscall_meta_##sname.enter_fiel 
ds), \ 
J; 
\ 
static struct syscall_metadata _ used \ 
_attribute_ ((section("__syscalls_metadata"))) \ 


*_ p syscall_meta_##sname = & syscall meta ##sname; 
a} 


若 内 核 配置 时 CONFIG_FTRACE_SYSCALLS 未 开启 ， 此 时 宏 SYSsCALL_METADATA 扩展 为 空 字符 串 : 


#define SYSCALL_METADATA(Sname, nb, ...) 


第 二 个 宏 SYSscALL_DEFINEX PRA 以 下 五 个 函数 的 定义 : 












































#define _ SYSCALL DEFINEx(x, name, ...) \ 
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS___) ) \ 
__attribute__((alias(__stringify(SyS##name)))); N 

\ 

static inline long SYSC##name(__MAP(x,__SC_DECL,__VA_ARGS__)); \ 
N 

asmlinkage long SyS##name(__MAP(x, _SC_LONG, _VA_ARGS_)); \ 
\ 

asmlinkage long SyS##name(__MAP(x,__SC_LONG, VA ARGS )) \ 
{ N 
long ret = SYSC##name(__MAP(x, _SC_CAST, _VA_ARGS_)); \ 
MAP(x,__SC_TEST,__VA_ARGS___); \ 
__PROTECT(x, ret, MAP(x, SC ARGS, VA ARGS  )); \ 

return ret; \ 

} \ 
\ 


static inline long SYSC##name(__MAP(x,__SC_DECL,__VA_ARGS___) ) 





第 一 个 函数 sys##name 是 给 定名 称 sys_system_call_name A AAAA BAN LL E 
Sc DECL 的 参数 有 ”VA ARGS 。 及 组 合 调 用 传 入 参数 系统 类 型 和 参数 名 称 ， 因 为 宏 定 义 中 
无 法 指定 参数 类 型 。 宏 _MAP 应 用 宏 sc bpEcL 给 _VA ARGS 参数 。 其 他 由 宏 

_ SYSCALL_DEFINEx 产生 的 函数 需要 protect from the CVE-2009-0029 此 处 不 必 深 入 研究 。 作 
为 宏 SYSCALL_DEFINE3 的 结论 : 


asmlinkage long sys_write(unsigned int fd, const char __user * buf, size_t count); 


现在 我 们 对 系统 调用 的 定义 有 一 定 了 解 ， 回 头 讨 论 write 系统 调用 的 实现 : 


SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf, 
size_t, count) 


{ 
struct fd f = fdget_pos(fd); 
ssize_t ret = -EBADF; 
if (f.file) { 
loff_t pos = file_pos_read(f.file); 
ret = vfs_write(f.file, buf, count, &pos); 
if (ret >= 0) 
file_pos_write(f.file, pos); 
fdput_pos(f); 
} 
return ret; 
} 


从 代码 可 知 ， 该 调用 有 三 个 参数 : 


© fd -文件 描述 符 ; 
e buf - 写 缓冲 区 ; 
@ count - 写 缓冲 区 大 小 . 


调用 的 功能 是 将 用 户 定义 的 缓冲 中 的 数据 写 入 指定 的 设备 或 文件 。 注 意 第 二 个 参数 buf , Æ 
LT _user 属性 。 该 属性 的 主要 目的 是 通过 sparse 工具 检查 Linux 内 核 代码 。sparse 定义 
-T [include/linux/compiler.h] 
(https://github.com/torvalds/linux/blob/master/include/linux/compiler.h) 头 文件 中 并 依赖 Linux 
内 核 的 ”cHECKER 定义 。 其 中 全 是 关于 sys write 系统 调用 的 有 用 元 信息 。 试 着 理解 该 系 
统 调用 的 实现 ， 定 义 从 fd 结构 类 型 的 f 结构 开始 ， 这 是 Linux 内 核 中 的 文件 描述 符 。 将 
调用 的 输出 传 入 fdget_pos 函数 。 fdget_pos 函数 在 相同 的 源 文 件 中 定义 ， 并 且 仅 作为 
_to fd HATA: 


static inline struct fd fdget_pos(int fd) 


{ 





return to_fd(__fdget_pos(fd)); 
} 


fdget_pos 的 主要 目的 是 将 仅仅 作为 的 数字 的 给 定 的 文件 描述 符 转化 为 fd 结构 。 通 过 一 长 
链 的 函数 调用 ， fdget_pos 函数 得 到 当前 进程 的 文件 描述 符 表 ， current->files , j 尝试 从 表 
中 获取 一 致 的 文件 描述 符 编号 。 当 获取 到 给 定 文件 描述 符 的 fd 结构 后 , 检查 文件 并 返回 文件 
是 否 存在 。 通 过 调用 函数 file_pos_read 获取 当前 处 于 文件 中 的 位 置 。 函 数 返 回 文件 的 

f_pos FR: 


Static inline lotfi t tile pos read(struct file *file) 


{ 


return file->f_pos; 


} 


之 后 调用 vfs write 函数 。 vfs_write 函数 在 源码 文件 fs/read_write.c 中 定义 。 其 功能 为 - 
向 指定 文件 的 指定 位 置 写 入 指定 缓冲 中 的 数据 。 此 处 不 深入 vfs_write 函数 的 细节 ， 因 为 这 
个 函数 与 系统 调用 没有 太 多 联系 ， 反 而 与 另 一 章节 Virtual file system 相 关 。 vfs_write 结束 相 
关 工 作 后 , 检查 结果 若 成 功 执行 ， 使 用 file_pos_write 函数 改变 在 文件 中 的 位 置 : 


if (ret >= 0) 
file_pos_write(f.file, pos); 


这 恰好 使 用 给 定 的 位 置 更 新 给 定 文件 的 f_pos : 


Static miine vord flesposawerce(stguet fale “fale Torf tpos) 


{ 


file->f_pos = pos; 


} 
在 write 系统 调用 处 理 函 数 的 结束 , CUP BHR: 
fdput_pos(f); 


解锁 在 共享 文件 描述 符 的 线程 并 发 写 文 件 时 保护 文件 位 置 的 互 矿 量 f_pos_lock ° 


我 们 讨论 了 Linux 内 核 提供 的 系统 调用 的 部 分 实现 。 显 然 略 过 了 write 系统 调用 的 部 分 实现 
细节 ， 正 如 文中 所 述 , 在 该 章节 中 仅 关 心 系统 调用 的 相关 内 容 ， 不 讨论 与 其 他 子 系统 相关 的 内 
容 ， 例 如 Virtual file system. 
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总 结 Linux 内 核 中 关于 系统 调用 概念 的 the first part covering system call concepts in the Linux 
kernel. 本 节 中 讨论 了 系统 调用 的 原理 ， 接 下 来 的 一 节 将 深入 该 主题 ， 了 解 Linux 内 核 系统 调 
用 相关 代码 。 


若 存在 疑问 及 建议 , 在 twitter @OxAX, 通过 email 或 者 创建 issue. 


由 于 英语 是 我 的 第 一 语言 由 此 造成 的 不 便 深 感 抱歉 。 若 发 现 错误 请 提交 PR 至 linux-insides. 
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Linux 系统 内 核 调用 第 二 节 


Linux 内 核 如 何 处 理 系统 调用 


前 一 小 节 作为 本 章节 的 第 一 部 分 描述 了 Linux 内 核 system call 概念 。 前 一 节 中 提 到 通常 系统 
调用 处 于 内 核 处 于 操作 系统 层面 。 前 一 节 内 容 从 用 户 空 间 的 角度 介绍 ， 并 且 write 系统 调用 实 
现 的 一 部 分 内 容 没 有 讨论 。 在 这 一 小 节 继 续 关注 系统 调用 ， 在 深入 Linux 内 核 之 前 ， 从 一 些 
理论 开始 。 


程序 中 一 个 用 户 程序 并 不 直接 使 用 系统 调用 。 我 们 并 未 这 样 写 Hello world 程序 代码 : 


int main(int argc, char **argv) 


{ 


sys_write(fd1, buf, strien(buf)); 


我 们 可 以 使 用 与 C standard library 帮助 类 似 的 方式 : 


#include <unistd.h> 


int main(int argc, char **argv) 


{ 
write(fdi, buf, strien(buf)); 
不 管 怎样 ， write 不 是 直接 的 系统 调用 也 不 是 内 核 函 数 。 程 序 必 须 将 通用 目的 寄存 器 按照 正 


确 的 顺序 存 入 正确 的 值 ， 之 后 使 用 syscall 指令 实现 真正 的 系统 调用 。 在 这 一 节 我 们 关注 
Linux 内 核 中 ， 处 理 器 执行 syscall 指令 时 的 细节 。 


系统 调用 表 的 初始 化 


从 前 一 节 可 知 系统 调用 与 中 断 非常 相似 。 深 入 的 说 ， 系 统 调用 是 软件 中 断 的 处 理 程序 。 

此 ， 当 处 理 器 执行 程序 的 syscall 指令 时 ， 指 令 引 起 异常 导致 将 控制 权 转 移 至 异常 处 理 。 众 
所 周知 ， 所 有 的 异常 处 理 (或 者 内 核 C 函数 将 响应 异常 ) 是 放 在 内 核 代码 中 的 。 但 是 Linux 内 
核 如 何 查找 对 应 系统 调用 的 系统 调用 处 理 程序 的 地 址 ? Linux 内 核 由 一 个 特殊 的 表 : system 
call table ° 系统 调用 表 是 Linux 内 核 源码 文件 arch/x86/entry/syscall 64.c 中 定义 的 数 

组 sys_call table 的 对 应 。 其 实现 如 下 : 





asmlinkage const sys_call_ptr_t sys_call table[__NR_ syscall max+1] = { 
[0 ... __NR_syscall_max] = &sys_ni_syscall, 
#include <asm/syscalls_64.h> 


}; 


sys_call_table 数组 的 大 小 为 __NR_syscall_max + 1 ?’ _ NR syscall max 宏 作 为 给 定 架 构 
的 系统 调用 最 大 数量 。 这 本 书 关 于 x86 64 架构 , 因此 _NR_syscall max 为 322 ， 这 也 是 
本 书 编写 时 (当前 Linux 内 核 版 本 为 4.2.6-rc8+ ) 的 数字 。 编 译 内 核 时 可 通过 Kbuild 产 生 的 头 
文件 查看 该 宏 - include/generated/asm-offsets.h’: 


#define _ NR_syscall max 322 


对 于 x86_64 ，arch/x86/entry/syscalls/syscall 64.tbl 中 也 有 相同 的 系统 调用 数量 。 这 里 存 
在 两 个 重要 的 话题 ; sys_call_table 数组 的 类 型 及 数组 中 元 数 的 初始 值 。 首 

先 ， sys_call_ptr_t 为 指向 系统 调用 表 的 指针 。 其 是 通过 [typedef] E LKI By 348 Ft 89 
(https://en.wikipedia.org/wiki/Typedef) ， 和 返回 值 为 空 且 无 参数 : 


typedef void (*sys_call_ptr_t)(void); 


其 次 为 sys_call table 数组 中 元 素 的 初始 化 。 从 上 面 的 代码 中 可 知 ,数组 中 所 有 元 素 包 含 指 
向 sys_ni_syscall 的 系统 调用 处 理 器 的 指针 。 sys_ni_syscall 2A “not-implemented” 

调用 。 首先 ，sys_call table 的 所 有 元 素 指向 “not-implemented” 系统 调用 。 这 是 正确 的 初 

始 化 方法 ， 因 为 我 们 仅仅 初始 化 指向 系统 调用 处 理 器 的 指针 的 存储 位 置 ， 稍 后 再 做 处 理 。 
sys_ni_syscall 的 结果 比较 简单 , 仅仅 返回 -errno 或 者 -ENOSYS : 


asmlinkage long sys_ni_syscall(void) 


{ 
return -ENOSYS; 


} 


The -enosYs error tells us that: 


ENOSYS Function not implemented (POSIX.1) 


在 sys_call table 的 初始 化 中 同时 也 要 注意 ... 。 可 通过 GCC 编译 器 插件 - Designated 
Initializers 处 理 。 插 件 允 许 使 用 不 固定 的 顺序 初始 化 元 素 。 在 数组 结束 处 ， 我 们 引用 
asm/syscalls_64.h 头 文件 在 。 头 文件 由 特殊 的 脚本 arch/x86/entry/syscalls/syscalltbl.sh 从 
syscall table 产生 。 asm/syscalls_64.h 包括 以 下 宏 的 定义 : 


__SYSCALL_COMMON(9, sys_read, sys_read) 
__SYSCALL_COMMON(1, sys_write, sys_write) 
__SYSCALL_COMMON(2, SyS_open, sys_open) 
__SYSCALL_COMMON(3, sys_close, sys_close) 
__SYSCALL_COMMON(5, sys_newfstat, sys_newfstat) 


宏 __SYSCALL_common 在 相同 的 源码 中 定义 ， 作 为 宏 _SsYscALL 64 的 扩展 : 


#define _ SYSCALL COMMON(Nr, sym, compat) __SYSCALL_64(nr, sym, compat) 
#define __SYSCALL_64(nr, sym, compat) [nr] = sym, 


而 , 到 此 为 止 ，sys_call table 为 如 下 格式 : 


asmlinkage const sys_call_ptr_t sys_call_table[__NR_syscall_maxti] = { 





[0 ... __NR_syscall_max] = &sys_ni_syscall, 
[0] = sys_read, 
[1] = sys_write, 
[2] = sys_open, 


}; 


之 后 所 有 指向 “ non-implemented ”系统 调用 元 素 的 内 容 为 ”sys_ni_syscall BAA ws > RH 
数 仅 返回 -ENOSYS ° 其 他 元 素 指 向 sys_syscall_name 函数 。 


至 此 , 完成 系统 调用 表 的 填充 并 且 Linux 内 核 了 解 系统 调用 处 理 器 的 为 值 。 但 是 Linux 内 核 在 
处 理 用 户 空间 程序 的 系统 调用 时 并 未 立即 调用 sys_syscall_name 函数 。 记 住 关于 中 断 及 中 DT 
处 理 的 章节 。 当 Linux 内 核 获得 处 理 中 断 的 控制 权 , 在 调用 中 断 处 理 程序 前 ， 必 须 做 一 些 准 备 
如 保存 用 户 空 间 寄存 器 ， 切 换 至 新 的 堆栈 及 其 他 很 多 工作 。 系 统 调 用 处 理 也 是 相同 的 情形 。 

第 一 件 事 是 处 理 系统 调用 的 准备 ， 但 是 在 Linux 内 核 开 始 这 些 准备 之 前 , 系统 调用 的 入 口 必须 
完成 初始 化 ， 同 时 只 有 Linux 内 核 知 道 如 何 执行 这 些 准备 。 在 下 一 章节 我 们 将 关注 Linux AK 
中 关于 系统 调用 入 口 的 初始 化 过 程 。 


系统 调用 入 口 初 始 化 


当 系 统 中 发 生 系统 调用 , 开始 处 理 调用 的 代码 的 第 一 个 字 节 在 什么 地 方 ? 阅读 Intel 的 手册 - 
64-ia-32-architectures-software-developer-vol-2b-manual: 


SYSCALL 引起 操作 系统 系统 调用 处 理 器 处 于 特权 级 9， 通过 加 载 ITA32_LSTAR MSR 至 RIP 完 成 。 


这 就 是 说 我 们 需要 将 系统 调用 入 口 放置 到 IA32_LSTAR model specific register 。 这 一 操作 在 
Linux 内 核 初始 过 程 时 完成 。 若 已 阅读 关于 Linux 内 核 中 断 及 中 断 处 理 政界 的 第 四 节 , Linux 
内 核 调用 在 初始 化 过 程 中 调用 trap_init 元 数 。 该 函数 在 arch/x86/kernel/setup.c 源 代码 文 
件 中 定义 ， 执 行 non-early 异常 处 理 (如 除法 错误 ， 协 处 理 器 错误 等 ) 的 初始 化 。 除 了 
non-early 异常 处 理 的 初始 化 外 , 函数 调用 arch/x86/kernel/cpu/common.c 中 cpu_init & 
数 ， 调 用 相同 源码 文件 中 的 syscall init 完成 per-cpu 状态 初始 化 。 


该 函数 执行 系统 调用 入 口 的 初始 化 。 查 看 函数 的 实现 ， 函 数 没有 参数 且 首 先 坊 充 两 个 特殊 模 
块 寄存 器 : 


wrmsrl(MSR_STAR, ((u64) USER32 CS)<<48 | ((u64)__KERNEL_CS)<<32); 
wrmsrl(MSR_LSTAR, entry_SYSCALL_64); 


第 一 个 特殊 模块 集 寄存 器 - MSR_STAR 的 63:48 为 用 户 代 码 的 代码 段 。 这 些 数据 将 加 载 至 

cs 和 ss 段 选择 符 ， 由 提供 将 系统 调用 返回 至 相应 特权 级 的 用 户 代 码 功 能 的 sysret 指令 
使 用 。 同 时 从 内 核 代码 来 看 ， 当 用 户 空 间 应 用 程序 执行 系统 调用 时 ， MSR_STAR 的 47:32 
将 作为 cs and ss 段 选择 寄存 器 的 基地 址 。 第 二 行 代码 中 我 们 将 使 用 系统 调用 入 

口 entry_SYSCALL 64 填充 MSR_LSTAR 寄存 器 。 entry SYSCALL 64 在 
arch/x86/entry/entry_64.S 汇编 文件 中 定义 ， 和 包含 系统 调用 执行 前 的 准备 (上 面 已 经 提 及 这 些 
准备 ) 。 目 前 不 关注 entry_SYSCALL 64 ,将 在 章节 的 后 续 讨论 。 


在 设置 系统 调用 的 入 口 之 后 ， 需 要 以 下 特殊 模式 寄存 器 : 


e MSR_CSTAR -target rip for the compability mode callers; 
© MSR_IA32_SYSENTER_cS -target cs forthe sysenter instruction; 
© MSR_IA32_SYSENTER_ESP -target esp forthe sysenter instruction; 


© MSR_IA32_SYSENTER_EIP -target eip forthe sysenter instruction. 


这 些 特殊 模式 寄存 器 的 值 与 内 核 配 置 选项 CONFIG_IA32 EMULATION 有 关 。 若 开 局 该 内 核 配 置 
选项 ， 允 许 64 字 节 内 核 运 行 32 字 节 的 程序 。 首先 , 若 CONFIG_IA32_EMULATION 内 会 配置 选项 
开启 , 将 使 用 兼容 模式 的 系统 调用 入 口 填充 这 些 特殊 模式 寄存 器 : 


wrmsrl(MSR_CSTAR, entry_SYSCALL_compat); 


对 于 内 核 代 码 段 , 将 堆栈 指针 置 零 ， entry_SYSENTER_compat 字 的 地 址 写 入 指令 指针 : 


wrmsrl_safe(MSR_IA32_SYSENTER_CS, (u64)_KERNEL_CS); 
wrmsrl_safe(MSR_IA32_SYSENTER_ESP, QOULL); 
wrmsrl_safe(MSR_IA32_SYSENTER_EIP, (u64)entry_SYSENTER_compat) ; 


另 一 方面 , 若 CONFIG_IA32_EMULATION 内 核 配 置 选项 未 开局 , 将 把 ignore_sysret FH 
入 MSR_CSTAR : 


wrmsrl(MSR_CSTAR, ignore_sysret); 


# # arch/x86/entry/entry_64.S 汇编 文件 中 定义 ， 仅 返回 -ENOSYS 错误 代码 : 


ENTRY(ignore_sysret) 
mov $-ENOSYS, %eax 
sysret 
END(ignore_sysret) 


现在 需要 像 之 前 代码 一 样 填充 MSR_IA32_SYSENTER_CS , MSR_IA32_SYSENTER_ESP , 
MSR_IA32_SYSENTER_EIP 特殊 模式 寄存 器 ， 当 CONFIG_IA32_EMULATION 内 核 配置 选项 打开 时 。 
在 这 种 情况 ( CONFIG_IA32_EMULATION 配置 选项 未 设置 ) VF ALBA FL MSR_IA32_SYSENTER_ESP 和 

MSR_IA32_SYSENTER_EIP ， 同 时 将 Global Descriptor Table 的 无 效 段 加 载 至 


MSR_IA32_SYSENTER_CS 特殊 模式 寄存 器 : 


wrmsrl_safe(MSR_IA32_SYSENTER_CS, (u64)GDT_ENTRY_INVALID_SEG); 
wrmsrl_safe(MSR_IA32_SYSENTER_ESP, OULL); 
wrmsrl_safe(MSR_IA32_SYSENTER_EIP, OULL); 


可 以 从 描述 Linux 内 核 启 动 过 程 的 章节 阅读 更 多 关于 Global Descriptor Table 的 内 容 。 


在 syscall_init 函数 的 结束 , 通过 写 入 MsSR_SYSCALL_MASK 特殊 寄存 器 的 标志 位 ， 将 标志 寄 


ER 中 的 标志 位 屏 项 : 


wrmsr1(MSR_SYSCALL_MASK, 
X86_EFLAGS_TF|X86_EFLAGS_DF | X86_EFLAGS_IF | 
X86_EFLAGS_IOPL |X86_EFLAGS_AC|X86_EFLAGS_NT); 








这 些 标志 位 将 在 syscall 初始 化 时 清除 。 至 此 ，syscall_init 函数 结束 也 意味 着 系统 调用 已 
经 可 用 。 现 在 我 们 关注 当 用 户 程序 执行 syscall 指令 发 生 什 么 。 


系统 调用 处 理 执行 前 的 准备 


如 之 前 写 到 , 系统 调用 或 中 断 处 理 在 被 Linux 内 核 调 用 前 需要 一 些 准备 。 宏 idtentry AR 
常 处 理 被 执行 前 的 所 需 准备 ， 宏 interrupt 完成 中 断 处 理 被 调用 前 的 所 需 准 备 
> entry_SYSCALL_64 完成 系统 调用 执行 前 的 所 需 准 备 。 


entry_SYSCALL_64 在 arch/x86/entry/entry_64.S 汇编 文件 中 定义 ， 从 下 面 的 宏 开 始 : 


SWAPGS_UNSAFE_STACK 


该 宏 在 arch/x86/include/asm/irqflags.h 头 文件 中 定义 ， 扩 展 swapgs 指令 : 


#define SWAPGS_UNSAFE_STACK swapgs 


宏 将 交换 GS 段 选择 符 及 MSR_KERNEL_GS_BASE 特殊 模式 寄存 器 中 的 值 。 换 和 句 话说 ， 将 其 入 内 
核 堆栈 。 之 后 使 老 的 堆栈 指针 指向 rsp_scratch per-cpu 变量 设置 堆栈 指针 指向 当前 处 理 器 
的 栈 顶 : 


movd %rsp, PER_CPU_VAR(rsp_scratch) 
movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp 


下 一 步 中 将 堆栈 段 及 老 的 堆栈 指针 如 栈 : 


pushq $__USER_DS 
pushq PER_CPU_VAR(rsp_scratch) 


之 后 使 能 中 断 , 因为 入 口中 断 被 关闭 ， 保 存 通用 目的 TGA (M bp, bx A ri2 至 ris), 
标志 位 ,“ non-implemented ”系统 调用 相关 的 -enosys 及 代码 段 寄 存 器 至 堆栈 : 


ENABLE_INTERRUPTS(CLBR_NONE) 


pushq %r11 

pushq $__USER_CS 
pushq %r CX 

pushq %r ax 

pushq %r di 

pushq %r Si 

pushq %r dx 

pushq %r CX 

pushq $-ENOSYS 
pushq %r 8 

pushq %r9 

pushq %r10 

pushq %r 11 

sub $(6*8), %rsp 


当 系 统 调 用 由 用 户 空 间 程序 引起 时 , 通用 目的 寄存 器 状态 如 下 : 


e rax -contains system call number; 

e rcx -contains return address to the user space; 

e r11 -contains register flags; 

e rdi -contains first argument of a system call handler; 

e rsi -contains second argument of a system call handler; 
e rdx - contains third argument of a system call handler; 

e r10 -contains fourth argument of a system call handler; 
e rs -contains fifth argument of a system call handler; 

e r9 -contains sixth argument of a system call handler; 


其 他 通用 目的 寄存 器 (如 rop, rbx 和 raz 至 ri5 ) ÆC ABI) 保 留 。 将 寄存 器 标志 位 如 
栈 ， 之 后 是 “non-implemented "系统 调用 的 用 户 代码 段 ， 用 户 空间 返回 地 址 ， 系 统 调用 编 
号 ， 三 个 参数 ，dump 错误 代码 和 堆栈 中 的 其 他 信息 。 


下 一 步 检 查 当 前 thread_info 中 的 _TIF_WORK_SYSCALL_ENTRY : 


testl $_TIF_WORK_SYSCALL_ENTRY, ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) 
jnz tracesys 


宏 _TIF_WORK_SYSCALL_ENTRY 在 arch/x86/include/asm/thread_info.h 头 文件 中 定义 ， 提 供 一 系 
列 与 系统 调用 跟踪 有 关 的 进程 信息 标志 : 


#define _TIF_WORK_SYSCALL_ENTRY \ 


(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_EMU | _TIF_SYSCALL_AUDIT | \ 
_TIF_SECCOMP | _TIF_SINGLESTEP | _TIF_SYSCALL_TRACEPOINT | \ 
_TIF_NOHZ) 


本 章节 中 不 讨论 追踪 /调试 相关 内 容 ,将 在 关于 Linux 内 核 调 斌 及 追踪 相关 独立 章节 中 讨论 。 在 
tracesys 标签 之 后 , 下 一 标签 为 entry_SYSCALL 64 fastpath .在 entry_SYSCALL_64_fastpath 
中 检查 头 文件 arch/x86/include/asm/unistd.h 中 定义 的 __sYScALL_MASK 


# ifdef CONFIG X86 X32_ABI 

# define _ SYSCALL MASK (~(__X32_SYSCALL_BIT)) 
# else 

# define _ SYSCALL_MASK (~0) 

# endif 


”X32 SYSCALL BIT 为 : 


#define __X32_SYSCALL_BIT 0x40000000 


众所周知 ， SYScALL_MASK 与 CONFIG_X86_X32 ABI 内 核 配置 选项 相关 ， 作 为 64 位 内 核 中 
32 位 ABI 的 掩 码 。 


So we check the value of the _ syscALL_MASK and if the coNFIG x86 x32 ABI is disabled we 
compare the value of the rax register to the maximum syscall number ( _ NR_syscall max ), 
alternatively if the cworIG x86 x32 ABI is enabled we mask the eax register with the 
__X32_SYSCALL_BIT and do the same comparison: 


#if __SYSCALL_MASK == ~0 

cmpq $__NR_syscall_max, %rax 
#else 

andl $__SYSCALL_MASK, %eax 

cmpl $__NR_syscall_max, %eax 
#endif 


至 此 检查 最 后 一 调 比 较 指令 的 结果 ， ja 指令 在 co 和 zF 标志 为 0 时 执行 : 


若 正确 调用 系统 调用 , 从 rio 移动 第 四 个 参数 至 rcx ， 保 持 x86 64 C ABI 开启 ， 同 时 以 系 
统 调 用 的 处 理 程序 的 地 址 为 参数 执行 call 指令 : 


movq %r10, %rcx 
call *sys_call_table(, %rax, 8) 


注意 , 上 文 提 到 sys_call table 是 一 个 数组 。 rax 通用 目的 寄存 器 为 系统 调用 的 编号 ， 且 
sys_call_table 的 每 个 元 素 为 8 字 节 。 因此 使 用 *sys_call_table(, %rax, 8) 符号 找到 指 
定 系统 调用 处 理 在 sys_call table 中 的 偏 移 。 


就 这 样 。 完 成 了 所 需 的 准备 ， 系 统 调 用 处 理 将 被 相应 的 中 断 处 理 调用 。 例如 Linux 内 核 代 码 
中 SYSCALL_DEFINE[N] 宏 定义 的 sys_read ，sys_write 和 其 他 中 断 处 理 。 


退出 系统 调用 
在 系统 调用 处 理 完成 人 物 后 , 将 退回 arch/x86/entry/entry 64.S, 正好 在 系统 调用 之 后 : 


call *sys_call_table(, %rax, 8) 


在 从 系统 调用 处 理 返回 之 后 ， 下 一 步 是 将 系统 调用 处 理 的 返回 值 入 栈 。 系 统 调用 将 用 户 程序 
的 返回 结果 放置 在 通用 目的 寄存 器 rax 中 ,因此 在 系统 调用 处 理 完 成 其 工作 后 ， 将 寄存 器 的 值 
AR : 


movd %rax, RAX(%rsp) 


在 Rax 指定 的 位 置 。 


之 后 调用 在 arch/x86/include/asm/irqflags.h 中 定义 的 宏 LOCKDEP_SYS_EXIT : 


LOCKDEP_SYS_EXIT 


宏 的 实现 与 CONFIG_DEBUG_LOCK_ALLOC 内 核 配 置 选项 相关 ， 该 配置 允许 在 退出 系统 调用 时 调试 
锁 。 再 次 强调 ， 在 该 章节 不 关注 ， 将 在 单独 的 章节 讨论 相关 内 容 。 在 entry_sYscALL 64 函数 
的 最 后 ， 恢 复 除 rxe 和 ra 外 所 有 通用 寄存 器 , AA rcx 寄存 器 为 调用 系统 调用 的 应 用 
程序 的 返回 地 址 ， ra 寄存 器 为 老 的 flags register. 在 恢复 所 有 通用 寄存 器 之 后 ， 将 在 

rex 中 装 入 返回 地 址 ，r11 寄存 器 装 入 标志 ， rsp 装 入 老 的 堆栈 指针 : 


RESTORE_C_REGS_EXCEPT_RCX_R11 





movq RIP(%rsp), %rcx 
movq EFLAGS(%rsp), %r11 
movq RSP(%rsp), %rsp 


USERGS_SYSRET64 


最 后 仅仅 调用 宏 USERGS_SYSRET64 ， 其 扩展 调用 swapgs 指令 交换 用 户 cs AK GS? 
sysretq 指令 执行 从 系统 调用 处 理 退 出 。 


#define USERGS_SYSRET64 \ 
swapgs; \ 
sysretq,; 


现在 我 们 知道 ， 当 用 户 程序 使 用 系统 调用 时 发 生 的 一 切 。 整 个 过 程 的 步骤 如 下 : 


e 用 户 程序 中 的 代码 装 入 通用 目的 寄存 器 的 值 (系统 调用 编号 和 系统 调用 的 参数 ) ; 

© 处 理 器 从 用 户 模式 切换 到 内 核 模式 开始 执行 系统 调用 入 口 - entry SYSCALL_64 ; 

e entry_SYSCALL_64 切换 至 内 核 堆栈 ， 在 堆栈 中 存 通 用 目的 寄存 器 , 老 的 堆栈 ， 代 码 段 , 标 
志 位 等 ; 

e entry_SYSCALL 64 检查 ras 寄存 器 中 的 系统 调用 编号 ,系统 调用 编号 正确 时 ， 在 
sys_call_table 中 查找 系统 调用 处 理 并 调用 ; 

© 若 系 统 调 用 编号 不 正确 , 跳 至 系统 调用 退出 ; 

© 系统 调用 处 理 完成 工作 后 , 恢复 通用 寄存 器 , 老 的 堆栈 ， 标 志 位 及 返回 地 址 ， 通 


过 sysretq 指令 退出 entry_SYSCALL_64 . 


Linux 内 核 如 fay Zh FE A 统 调 用 


L V4 


这 是 Linux 内 核 相 关 概 念 的 第 二 节 。 在 前 一 节 ， 从 用 户 应 用 程序 的 角度 讨论 了 这 些 概念 的 原 
理 。 在 这 一 节 继 续 深 入 系统 调用 概念 的 相关 内 容 ， 讨 论 了 系统 调用 发 生 时 Linux 内 核 执 行 的 


若 存在 疑问 及 建议 , 在 twitter @OxAX, 通过 email 或 者 创建 issue. 


由 于 英语 是 我 的 第 一 语言 由 此 造成 的 不 便 深 感 抱歉 。 若 发 现 错误 请 提交 PR 至 linux-insides. 
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Linux 内 核 系统 调用 第 三 节 


vsyscalls 和 vDSO 


这 是 讲解 Linux 内 核 中 系统 调用 章节 的 第 三 部 分 ， 前 一 节 讨 论 了 用 户 空 间 应 用 程序 发 起 的 系 
统 调用 的 准备 工作 及 系统 调用 的 处 理 过 程 。 we 文 一 节 将 讨论 两 个 与 系统 调用 十 分 相似 的 概 


念 ， 这 两 个 概念 是 vsyscall 和 vdso ° 


我 们 已 经 了 解 什 么 是 系统 调用 。 这 是 Linux 内 核 一 种 特殊 的 运行 机 制 ， 使 得 用 户 空间 的 应 用 程 
序 可 以 请 求 ， 像 写 入 文件 和 打开 套 接 字 等 特权 级 下 的 任务 。 正 如 你 所 了 解 的 ， 在 Linux AK 
中 发 起 一 个 系统 调用 是 特别 昂贵 的 操作 ， 因 为 处 理 器 需要 中 断 当 前 正在 执行 的 任务 ， 切 换 内 
核 模 式 的 上 下 文 ， 在 系统 调用 处 理 完 毕 后 跳 转 至 用 户 空 间 。 以 下 的 两 种 机 制 - vsyscall 和 d 
vdso 被 设计 用 来 加 速 系 统 调用 的 处 理 ， 在 这 一 节 我 们 将 了 解 两 种 机 制 的 工作 原理 。 


vsyscalls 介绍 


vsyscall 或 virtual system call 是 第 一 种 也 是 最 古老 的 一 种 用 于 加 快 系统 调用 的 机 制 。 
vsyscall 的 工作 原则 其 实 十 分 简单 。Linux 内 核 在 用 户 空间 映射 一 个 包含 一 些 变量 及 一 些 系 
统 调 用 的 实现 的 内 存 页 。 对 于 X86 64 架构 可 以 在 Linux 内 核 的 [文档 ] 
(https://github.com/torvalds/linux/blob/master/Documentation/x86/x86_64/mm.txt) 找到 关于 
一 内 存 区 域 的 信息 : 


ffffffffff6060000 - ffffffffffdfffff (=8 MB) vsyscalls 


或 : 


~$ sudo cat /proc/i/maps | grep vsyscall 
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] 


因此 , 这 些 系统 调用 将 在 用 户 空间 下 执行 ， 这 意味 着 将 不 发 生 上 下 文 切换 。 vsyscall AGH 
的 映射 在 arch/x86/entry/vsyscall/vsyscall_64.c 源 代码 中 定义 的 map_vsyscall WAP KH © 
这 一 函数 在 Linux 内 核 初始 化 时 被 arch/x86/kernel/setup.c 源 代码 中 定义 的 函数 setup_arch 
(我 们 在 第 五 章 Linux 内 核 的 初始 化 中 讨论 过 该 函数 )。 


注意 map_vsyscall 函数 的 实现 依赖 于 内 核 配置 选项 CONFIG_X86_VSYSCALL_EMULATION : 


#ifdef CONFIG_X86_VSYSCALL_EMULATION 
extern void map_vsyscall(void); 
#else 


static inline void map_vsyscall(void) {} 
#endif 


正如 帮助 文档 中 所 描述 的 ，CONFIG X86_VSYSCALL_EMULATION 配置 选项 : 使 能 vsyscall 模拟 . A 
何 模拟 vsyscall ? 事实 上 ，vsyscall 由 于 安全 原因 是 一 种 遗留 AB| o Æ RATAA RA R 
定 的 地 址 , 意味 着 vsyscall 的 内 存 页 的 位 置 在 任何 时 刻 是 相同 ， 这 一 位 置 是 在 
map_vsyscall 部 数 中 指定 的 。 这 一 芳 数 的 实现 如 下 : 


void __init map_vsyscall(void) 
{ 


extern char __vsyscall_page; 
unsigned long physaddr_vsyscall = __pa_symbol(&__vsyscall_page); 


在 map_vsyscall 函数 的 开始 ， 通 过 宏 pa symbool 获取 了 vsyscall 内 存 页 的 物理 地 址 (我 
们 已 在 第 四 章 of the Linux kernel initialization process) 讨 论 了 该 宏 的 实 

现 ) ° _vsyscall page 在 arch/x86/entry/vsyscall/vsyscall_emu_64.S 汇编 源 代码 文件 中 定 
义 ， 具 有 如 下 的 虚拟 地 址 : 


ffffffff81881000 D __vsyscall_page 


在 .data..page_aligned, aw 段 中 包含 如 下 三 中 系统 调用 : 


e gettimeofday ; 
@ time ; 


e getcpu . 


或 : 


__vsyscall_page: 
mov $_NR_gettimeofday, %rax 
syscall 
ret 


.balign 1024, Oxcc 
mov $_NR_time, %rax 
syscall 

ret 


.balign 1024, Oxcc 

mov $_NR_getcpu, %rax 
syscall 

ret 


回 到 map_vsyscall 函数 及 _vsyscall_page 的 实现 ， 在 得 到 _ vsyscall_page 的 物理 地 址 
之 后 ， 使 用 ”set fixmap 为 vsyscall 内 存 页 检查 设置 fix-mapped 地 址 的 变 


= vsyscall_mode 


if (vsyscall_mode != NONE) 
__set_fixmap(VSYSCALL_PAGE, physaddr_vsyscall, 
vsyscall_mode == NATIVE 
? PAGE_KERNEL_VSYSCALL 
: PAGE_KERNEL_VVAR) ; 


The _ set fixmap takes three arguments: The first is index of the fixed_addresses enum. 
In our case vsYSCALL_PAGE is the first element of the fixed_addresses enum forthe xs6_64 
architecture: 


enum fixed_addresses { 


#ifdef CONFIG_X86_VSYSCALL_EMULATION 
VSYSCALL_PAGE = (FIXADDR_TOP - VSYSCALL_ADDR) >> PAGE_SHIFT, 
#endif 


该 变量 值 为 511 。 第 二 个 参数 为 映射 内 存 页 的 物理 地 址 ， 第 三 个 参数 为 内 存 页 的 标志 位 。 注 
意 VSYSCALL_PAGE 标 志 位 依赖 于 变量 vsyscall_mode ° 4 vsyscall_mode 变量 为 NATIVE 
时 ， 标 志 位 为 ”PAGE_KERNEL_VSYSCALL ， 其 他 情况 则 是 PAGE_KERNEL_WAR ° RK ( 


PAGE_KERNEL_VSYSCALL 及 PAGE_KERNEL_VVAR ) 都 将 被 扩展 以 下 标志 : 





#define PAGE_KERNEL_VSYSCALL (__PAGE_KERNEL_RX | _PAGE_USER) 
#define PAGE_KERNEL_VVAR (__PAGE_KERNEL_RO | _PAGE_USER) 











标志 反映 了 vsyscall 内 存 页 的 访问 权限 。 两 个 标志 都 带 有 _pace_useR 标志 ， 这 意味 着 内 
存 页 可 被 运行 于 低 特 权 级 的 用 户 模式 进程 访问 。 第 二 个 标志 位 取决 于 vsyscall mode 变量 的 
值 。 第 一 个 标志 ( __PAGE_KERNEL_VSYSCALL ) 在 vsyscall_mode A NATIVE 时 被 设 定 。 这 意味 
着 虚拟 系统 调用 将 以 本 地 syscall 指令 的 方式 执行 。 另 一 情况 下 ， 在 vsyscall mode 为 
emulate 时 vsyscall 为 ”PAGE_KERNEL_VVAR ， 此 时 系统 调用 将 被 置 于 陷阱 并 被 合理 的 模拟 。 


vsyscall_mode 变量 通过 vsyscall_setup 获取 值 : 





static int Init vsyscall_setup(char *str) 


{ 
if (str) { 
if (!strcmp("emulate", str)) 
vsyscall_mode = EMULATE; 
else if (!strcmp("native", str)) 
vsyscall_mode = NATIVE; 
else if (!strcmp("none", str)) 
vsyscall_mode = NONE; 
elise 
return -EINVAL; 
return 0; 
} 
return -EINVAL; 
} 


函数 将 在 早期 的 内 核 分 析 时 被 调用 : 


early_param("vsyscall", vsyscall setup); 


关于 early_param 宏 的 更 多 信息 可 以 在 第 六 章 Linux 内 核 初 始 化 中 找到 。 


在 函数 vsyscall map 的 最 后 仅 通过 BUILD BUG ON 宏 检 查 vsyscall 内 存 页 的 虚拟 地 址 
是 否 等 于 变量 VSYSCALL_ADDR 


BUILD_BUG_ON( (unsigned long) fix_to_virt(VSYSCALL_PAGE) != 
(unsigned long)VSYSCALL_ADDR); 


就 这 样 vsyscall 内 存 页 设置 完 完毕 。 上 述 的 结果 如 下 : FAE vsyscall=native 内 核 命令 行 
参数 ， 虚 拟 内 存 调 用 将 以 arch/x86/entry/vsyscall/vsyscall emu 64.S 文件 中 本 地 系统 调用 
指令 的 方式 执行 。glibc 知道 虚拟 系统 调用 处 理 器 的 地 址 。 注 意 虚 拟 系统 调用 的 地 址 以 1024 
(或 ox460 ) 比特 对 齐 。 


__vsyscall_page: 
mov $_NR_gettimeofday, %rax 
syscall 
ret 


.balign 1024, Oxcc 
mov $_NR_time, %rax 
syscall 

ret 


.balign 1024, Oxcc 

mov $_NR_getcpu, %rax 
syscall 

ret 


vsyscall 内 存 页 的 起 始 地 址 为 ”ffffffffff600000 。 因 此 , glibc 知道 所 有 虚拟 系统 调用 处 理 
器 的 地 址 。 可 以 在 glibc 源码 中 找到 这 些 地 址 的 定义 : 


#define VSYSCALL_ADDR_vgettimeofday  Oxffffffffff600000 
#define VSYSCALL_ADDR_vtime Oxffffffffff600400 
#define VSYSCALL ADDR_vgetcpu Oxffffffffff600800 


所 有 的 虚拟 系统 调用 请 求 都 将 映射 至 __vsyscall_page + VSYSCALL_ADDR_vsyscall_name 偏 置 ， 
将 虚拟 内 存 系统 调用 的 编号 置 于 通用 目的 寄存 器 ， 本 地 的 X86_64 系统 调用 指令 将 被 执行 。 


在 第 二 种 情况 中 , 若 将 vsyscall=emulate 参数 传递 给 内 核 命令 行 , 提升 虚拟 系统 调用 处 理 器 的 
尝试 导致 一 个 page fault 异常 。 谨 记 ，vsyscall 内 存 页 具有 PAGE _KERNEL_VVAR 的 访问 权 
限 ， 这 将 禁止 执行 。 do_page_fault MA wer 或 page fault 的 处 理 器 。 它 将 尝试 了 解 最 
后 一 次 page fault 的 原因 。 一 种 可 能 的 场景 是 vsyscall 模式 为 emulate 情况 下 的 虚拟 系统 
调用 。 此 时 vsyscall 将 被 arch/x86/entry/vsyscall/vsyscall_ 64.c 源码 中 定义 的 
emulate_vsyscall 函数 处 理 。 





The emulate_vsyscall function gets the number of a virtual system call, checks it, prints 
error and sends segementation fault single: 


vsyscall_nr = addr_to_vsyscall_nr(address); 

if (vsyscall_nr < 0) { 
warn_bad_vsyscall(KERN_WARNING, regs, "misaligned vsyscall...); 
goto sigsegv; 


sigsegv: 
force_sig(SIGSEGV, current); 
reutrn true; 


As it checked number of a virtual system call, it does some yet another checks like 
access_ok violations and execute system call function depends on the number of a virtual 
system call: 


switch (vsyscall_nr) { 
case’ o: 
ret = sys_gettimeofday( 
(struct timeval __user *)regs->di, 
(struct timezone __user *)regs->si); 
break; 


In the end we put the result of the sys_gettimeofday or another virtual system call handler to 
the ax general purpose register, as we did it with the normal system calls and restore the 
instruction pointer register and add 8 bytes to the stack pointer register. This operation 
emulates ret instruction. 


regs->ax = ret; 
do_ret: 
regs->ip = caller; 


regs->sp += 8; 
return true; 


That's all. Now let's look on the modern concept - vpso . 


Introduction to vDSO 


As | already wrote above, vsyscall is an obsolete concept and replaced by the vpso or 

virtual dynamic shared object . The main difference between the vsyscall and vpso 
mechanisms is that vpso maps memory pages into each process in a shared object form, 
but vsyscall is static in memory and has the same address every time. For the xs6_64 
architecture it is called - linux-vdso.so.1 . All userspace applications linked with this shared 
library via the glibc . For example: 


~$ ldd /bin/uname 
linux-vdso.so.1 (0x00007ffe014b7000 ) 
libc.so.6 => /1ib64/libc.so.6 (0x00007fbfee2fe000 ) 
/11b64/1d-linux-x86-64.s0.2 (0x00005559aab7c000 ) 


Or: 


~$ sudo cat /proc/i/maps | grep vdso 
7FFF39F73000-7FFF39F75000 r-xp 00000000 00:00 0 [vdso] 


Here we can see that uname util was linked with the three libraries: 


e linux-vdso.so.1 ; 
© libc.so.6 ; 


© ild-linux-x86-64.s0.2 . 


The first provides vpso functionality, the second is c standard library and the third is the 
program interpreter (more about this you can read in the part that describes linkers). So, the 
vpso solves limitations of the vsyscall . Implementation of the vpso is similar to 


vsyscall . 


Initialization of the vpso occurs in the init_vdso function that defined in the 
arch/x86/entry/vdso/vma.c source code file. This function starts from the initialization of the 

vpso images for 32-bits and 64-bits depends on the conFic_xs6_x32_ABI kernel 
configuration option: 


static int Init init_vdso(void) 
{ 


init_vdso_image(&vdso_image_64) ; 


#ifdef CONFIG_X86_X32_ABI 
init_vdso_image(&vdso_image_x32); 
#endif 


Both function initialize the vdso_image structure. This structure is defined in the two 
generated source code files: the arch/x86/entry/vdso/vdso-image-64.c and the 
arch/x86/entry/vdso/vdso-image-64.c. These source code files generated by the vdso2c 


program from the different source code files, represent different approaches to call a system 
call like int 0x80 , sysenter and etc. The full set of the images depends on the kernel 
configuration. 


For example for the xs6_64 Linux kernel it will contain vdso_image_64 : 


#ifdef CONFIG_X86_64 
extern const struct vdso_image vdso_image_64; 
#endif 


But for the x86 - vdso_image_32 : 


#ifdef CONFIG_X86_X32 
extern const struct vdso_image vdso_image_x32; 
#endif 


If our kernel is configured for the xs6 architecture or for the xs6_64 and compability mode, 

we will have ability to call a system call with the int oxse interrupt, if compability mode is 

enabled, we will be able to call a system call with the native syscall instruction or 
sysenter instruction in other way: 


#if defined CONFIG_X86_32 || defined CONFIG_COMPAT 
extern const struct vdso_image vdso_image_32_int80; 
#ifdef CONFIG_COMPAT 
extern const struct vdso_image vdso_image_32_syscall; 
#endif 
extern const struct vdso_image vdso_image_32_sysenter; 
#endif 


As we can understand from the name of the vdso_image structure, it represents image of 

the vpso for the certain mode of the system call entry. This structure contains information 

about size in bytes of the vpso area that always a multiple of PAGE sIzE ( 4096 bytes), 

pointer to the text mapping, start and end address of the alternatives (set of instructions 

with better alternatives for the certain type of the processor) and etc. For example 
vdso_image_64 looks like this: 


const struct vdso_image vdso_image_64 = { 
.data = raw_data, 
.size = 8192, 
.text_mapping = { 
:name = "[vdso]", 
.pages = pages, 
}, 
.alt = 3145, 
.alt_len = 26, 
.sym_vvar_start = -8192, 
.sym_vvar_page = -8192, 
.sym_hpet_page = -4096, 
}; 


Where the raw data contains raw binary code of the 64-bit vpso system calls which are 
2 page size: 


static struct page *pages[2]; 


or 8 Kilobytes. 


The init_vdso_image function is defined in the same source code file and just initializes the 

vdso_image.text_mapping.pages . First of all this function calculates the number of pages and 
initializes each vdso_image.text_mapping.pages[number_of_page] with the virt_to_page 
macro that converts given address to the page structure: 


void _ init init_vdso_image(const struct vdso_image *image) 
{ 

anit ale 

int npages = (image->size) / PAGE_SIZE; 


for (i = 0; i < npages; i++) 
image->text_mapping.pages[i] = 
virt_to_page(image->data + i*PAGE_SIZE); 


The init_vdso function passed to the subsys_initcall macro adds the given function to 
the initcalls list. All functions from this list will be called in the do_initcalls function from 
the init/main.c source code file: 


subsys_initcall(init_vdso); 


Ok, we just saw initialization of the vpso and initialization of page structures that are 
related to the memory pages that contain vpso system calls. But to where do their pages 
map? Actually they are mapped by the kernel, when it loads binary to the memory. The 
Linux kernel calls the arch_setup_additional_pages function from the 
arch/x86/entry/vdso/vma.c source code file that checks that vpso enabled for the x86_64 
and calls the map_vdso function: 


int arch_setup_addit | ages(struct linux_binprm *bprm, int uses_interp) 


if (!vdso64_enabled) 
return 0; 


return map_vdso(&vdso_image_64, true); 


The map_vdso function is defined in the same source code file and maps pages for the 
vpso and forthe shared vpso variables. That's all. The main differences between the 
vsyscall andthe vpso concepts is that vsyscal has a static address of 
ffffffffff600000 and implements 3 system calls, whereas the vpso loads dynamically 

and implements four system calls: 


@ __vdso_clock_gettime ; 
e __vdso_getcpu ; 
© __vdso_gettimeofday ; 
e __vdso_time . 
That's all. 
Conclusion 


This is the end of the third part about the system calls concept in the Linux kernel. In the 
previous part we discussed the implementation of the preparation from the Linux kernel side, 
before a system call will be handled and implementation of the exit process from a system 
call handler. In this part we continued to dive into the stuff which is related to the system call 
concept and learned two new concepts that are very similar to the system call - the 

vsyscall andthe vopso. 


After all of these three parts, we know almost all things that are related to system calls, we 
know what system call is and why user applications need them. We also know what occurs 
when a user application calls a system call and how the kernel handles system calls. 


The next part will be the last part in this chapter and we will see what occurs when a user 
runs the program. 


If you have questions or suggestions, feel free to ping me in twitter OxAX, drop me email or 
just create issue. 


Please note that English is not my first language and | am really sorry for any 
inconvenience. If you found any mistakes please send me PR to linux-insides. 
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System calls in the Linux kernel. Part 4. 


How does the Linux kernel run a program 


This is the fourth part of the chapter that describes system calls in the Linux kernel and as | 
wrote in the conclusion of the previous - this part will be last in this chapter. In the previous 
part we stopped at the two new concepts: 


e vsyscall ; 


e vpso ; 
that are related and very similar on system call concept. 


This part will be last part in this chapter and as you can understand from the part's title - we 
will see what does occur in the Linux kernel when we run our programs. So, let's start. 


how do we launch our programs? 


There are many different ways to launch an application from an user perspective. For 
example we can run a program from the shell or double-click on the application icon. It does 
not matter. The Linux kernel handles application launch regardless how we do launch this 
application. 


In this part we will consider the way when we just launch an application from the shell. As 
you know, the standard way to launch an application from shell is the following: We just 
launch a terminal emulator application and just write the name of the program and pass or 
not arguments to our program, for example: 


--version 
(GNU coreutils) 8.23 
Copyright (C) 2014 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. 
This is free software: you are free to change and redistribute it. 
There is NO WARRANTY, to the extent permitted by law. 





Written by Richard M. Stallman and David MacKenzie. 


Let's consider what does occur when we launch an application from the shell, what does 
shell do when we write program name, what does Linux kernel do etc. But before we will 
start to consider these interesting things, | want to warn that this book is about the Linux 
kernel. That's why we will see Linux kernel insides related stuff mostly in this part. We will 
not consider in details what does shell do, we will not consider complex cases, for example 
subshells etc. 


My default shell is - bash, so | will consider how do bash shell launches a program. So let's 
start. The bash shell as well as any program that written with C programming language 
starts from the main function. If you will look on the source code of the bash shell, you will 
find the main function in the shell.c source code file. This function makes many different 
things before the main thread loop of the bash started to work. For example this function: 


e checks and tries to open /dev/tty ; 

e check that shell running in debug mode; 

e parses command line arguments; 

e reads shell environment; 

e loads .bashrc , .profile and other configuration files; 
e and many many more. 


After all of these operations we can see the call of the reader_loop function. This function 
defined in the eval.c source code file and represents main thread loop or in other words it 
reads and executes commands. As the reader_loop function made all checks and read the 
given program name and arguments, it calls the execute_command function from the 
execute_cmd.c source code file. The execute_command function through the chain of the 
functions calls: 


execute_command 

--> execute_command_internal 
----> execute_simple_ command 
------ > execute_disk_command 
-------- > shell_execve 


makes different checks like do we need to start subshell , was it builtin bash function or 

not etc. As | already wrote above, we will not consider all details about things that are not 

related to the Linux kernel. In the end of this process, the shell execve function calls the 
execve system Call: 


execve (command, args, env); 


The execve system call has the following signature: 


int execve(const char *filename, char *const argv [], char *const envp[]); 


and executes a program by the given filename, with the given arguments and environment 
variables. This system call is the first in our case and only, for example: 


$ strace ls 
execve("/bin/1s", ["ls"], [/* 62 vars */]) = 0 


$ strace echo 
execve("/bin/echo", ["echo"], [/* 62 vars */]) = 0 


$ strace uname 
execve("/bin/uname", ["uname"], [/* 62 vars */]) = 0 


So, an user application ( bash in our case) calls the system call and as we already know the 
next step is Linux kernel. 


execve system call 


We saw preparation before a system call called by an user application and after a system 
call handler finished its work in the second part of this chapter. We stopped at the call of the 

execve system call in the previous paragraph. This system call defined in the fs/exec.c 
source code file and as we already know it takes three arguments: 


SYSCALL_DEFINE3(execve, 
const char __user *, filename, 
const char __user *const __user *, argv, 
const char __user *const __user *, envp) 


return do_execve(getname(filename), argv, envp); 


Implementation of the execve is pretty simple here, as we can see it just returns the result 
of the do_execve function. The do_execve function defined in the same source code file 
and do the following things: 


e Initialize two pointers on a userspace data with the given arguments and environment 
variables; 
e return the result of the do_execveat_common . 


We can see its implementation: 


struct user_arg_ptr argv = { .ptr.native = _ argv }; 
struct user_arg_ptr envp = { .ptr.native = __envp }; 


return do_execveat_common(AT_FDCWD, filename, argv, envp, ©); 


The do_execveat_common function does main work - it executes a new program. This function 
takes similar set of arguments, but as you can see it takes five arguments instead of three. 
The first argument is the file descriptor that represent directory with our application, in our 
case the AT_Fpcwp means that the given pathname is interpreted relative to the current 
working directory of the calling process. The fifth argument is flags. In our case we passed 

o tothe do_execveat_common . We will check in a next step, so will see it latter. 


First of all the do_execveat_common function checks the filename pointer and returns if it is 
NULL . After this we check flags of the current process that limit of running processes is not 
exceed: 


if (IS_ERR( filename) ) 
return PTR_ERR(filename) ; 


if ((current->flags & PF_NPROC_EXCEEDED) && 
atomic_read(&current_user()->processes) > rlimit(RLIMIT_NPROC)) { 
retval = -EAGAIN; 
goto out_ret; 


} 


current->flags &= ~PF_NPROC_EXCEEDED; 


If these two checks were successful we unset PF_NPROC_ EXCEEDED flag in the flags of the 
current process to prevent fail of the execve . You can see that in the next step we call the 

unshare_files function that defined in the kernel/fork.c and unshares the files of the current 
task and check the result of this function: 


retval = unshare_files(&displaced); 
if (retval) 
goto out_ret; 


We need to call this function to eliminate potential leak of the execve'd binary's file 
descriptor. In the next step we start preparation of the bprm that represented by the struct 
linux_binprm structure (defined in the include/linux/binfmts.h header file). The 1inux_binprm 
structure is used to hold the arguments that are used when loading binaries. For example it 
contains vma field which has vm_area_struct type and represents single memory area over 
a contiguous interval in a given address space where our application will be loaded, mm 

field which is memory descriptor of the binary, pointer to the top of memory and many other 
different fields. 


First of all we allocate memory for this structure with the kzalloc function and check the 
result of the allocation: 


bprm = kzalloc(sizeof(*bprm), GFP_KERNEL); 
if (!bprm) 
goto out_files; 


After this we start to prepare the binprm credentials with the call of the prepare_bprm_creds 
function: 


retval = prepare_bprm_creds(bprm); 
if (retval) 
goto out_free; 


check_unsafe_exec(bprm); 
current->in_execve = 1; 


Initialization of the binprm credentials in other words is initialization of the cred structure 
that stored inside of the linux_binprm structure. The cred structure contains the security 
context of a task for example real uid of the task, real guid of the task, uid and guid for 
the virtual file system operations etc. In the next step as we executed preparation of the 
bprm credentials we check that now we can safely execute a program with the call of the 
check_unsafe_exec function and set the current process to the in_execve state. 


After all of these operations we call the do_open_execat function that checks the flags that 
we passed to the do_execveat_common function (remember that we have o inthe flags ) 
and searches and opens executable file on disk, checks that our we will load a binary file 
from noexec mount points (we need to avoid execute a binary from filesystems that do not 
contain executable binaries like proc or sysfs), intializes file structure and returns pointer 
on this structure. Next we can see the call the sched_exec after this: 


file = do_open_execat(fd, filename, flags); 
retval = PTR_ERR(file); 
if (IS_ERR(file) ) 

goto out_unmark; 


sched_exec(); 


The sched_exec function is used to determine the least loaded processor that can execute 
the new program and to migrate the current process to it. 


After this we need to check file descriptor of the give executable binary. We try to check 
does the name of the our binary file starts from the / symbol or does the path of the given 
executable binary is interpreted relative to the current working directory of the calling 
process or in other words file descriptor is AT_Fpcwp (read above about this). 


If one of these checks is successfull we set the binary parameter filename: 


bprm->file = file; 


if (fd == AT_FDCWD || filename->name[0] == '/') { 
bprm->filename = filename->name; 


Otherwise if the filename is empty we set the binary parameter filename to the /dev/fd/%d 
or /dev/fd/%d/%s depends on the filename of the given executable binary which means that 
we will execute the file to which the file descriptor refers: 


} elise £ 
if (filename->name[0] == '\0') 
pathbuf = kasprintf(GFP_TEMPORARY, "/dev/fd/%d", fd); 
elise 


pathbuf = kasprintf(GFP_TEMPORARY, "/dev/fd/%d/%s", 
fd, filename->name) ; 
if (!pathbuf) { 
retval = -ENOMEM; 
goto out_unmark; 


bprm->filename = pathbuf; 


bprm->interp = bprm->filename; 


Note that we set not only the bprm->filename but also bprm->interp that will contain name 

of the program interpreter. For now we just write the same name there, but later it will be 

updated with the real name of the program interpreter depends on binary format of a 

program. You can read above that we already prepared cred for the linux_binprm . The 

next step is initalization of other fields of the 1inux_binprm . First of all we call the 
bprm_mm_init function and pass the bprm to it: 


retval = bprm_mm_init(bprm); 
if (retval) 
goto out_unmark; 


The bprm_mm_init defined in the same source code file and as we can understand from the 
function's name, it makes initialization of the memory descriptor or in other words the 
bprm_mm_init function initializes mm_struct structure. This structure defined in the 
include/linux/mm_types.h header file and represents address space of a process. We will 
not consider implementation of the bprm_mm_init function because we do not know many 
important stuff related to the Linux kernel memory manager, but we just need to know that 
this function initializes mm_struct and populate it with a temporary stack vm_area_struct . 


After this we calculate the count of the command line arguments which are were passed to 
the our executable binary, the count of the environment variables and set it to the bprm- 
>argc and bprm->enve respectively: 


bprm->argc = count(argv, MAX_ARG_STRINGS); 
if ((retval = bprm->argc) < 0) 
goto out; 


bprm->envc = count(envp, MAX_ARG_STRINGS); 
if ((retval = bprm->envc) < 0) 
goto out; 


As you can see we do this operations with the help of the count function that defined in the 
same source code file and calculates the count of strings in the argv array. The 

MAX_ARG_STRINGS macro defined in the include/uapi/linux/binfmts.h header file and as we can 
understand from the macro's name, it represents maximum number of strings that were 
passed to the execve system call. The value of the MAXx_ARG_STRINGS : 


#define MAX_ARG_STRINGS 0x7FFFFFFF 


After we calculated the number of the command line arguments and environment variables, 
we call the prepare_binprm function. We already call the function with the similar name 
before this moment. This function is called prepare_binprm_cred and we remember that this 
function initializes cred structure in the linux_bprm . Now the prepare_binprm function: 


retval = prepare_binprm(bprm); 
if (retval < 0) 
goto out; 


fills the linux_binprm structure with the uid from inode and read 128 bytes from the 
binary executable file. We read only first 128 from the executable file because we need to 
check a type of our executable. We will read the rest of the executable file in the later step. 
After the preparation of the linux_bprm structure we copy the filename of the executable 
binary file, command line arguments and enviroment variables to the 1linux_bprm with the 
call of the copy_strings_kernel function: 


retval = copy_strings_kernel(i, &bprm->filename, bprm); 
if (retval < 0) 
goto out; 


retval = copy_strings(bprm->envc, envp, bprm); 
if (retval < 0) 
goto out; 


retval = copy_strings(bprm->argc, argv, bprm); 
if (retval < 0) 
goto out; 


And set the pointer to the top of new program's stack that we set in the bprm_mm_init 
function: 


bprm->exec = bprm->p; 


The top of the stack will contain the program filename and we store this fileneme tothe 
exec field of the linux _bprm structure. 


Now we have filled linux_bprm structure, we call the exec_binprm function: 


retval = exec_binprm(bprm); 
if (retval < 0) 
goto out; 


First of all we store the pid and pid that seen from the namespace of the current task in the 


exec_binprm 


old_pid = current->pid; 

rcu_read_lock(); 

old_vpid = task_pid_nr_ns(current, task_active_pid_ns(current->parent) ); 
rcu_read_unlock(); 


and call the: 


search_binary_handler(bprm) ; 


function. This function goes through the list of handlers that contains different binary formats. 
Currently the Linux kernel supports following binary formats: 


e binfmt_script - Support for interpreted scripts that are starts from the #! line; 
e binfmt_misc -Support differnt binary formats, according to runtime configuration of the 
Linux kernel; 


e binfmt_elf -Support elf format; 

e binfmt_aout - Support a.out format; 

e binfmt_flat - support for flat format; 

© binfmt_elf_fdpic - Support for elf FDPIC binaries; 

e binfmt_em86 - support for Intel elf binaries running on Alpha machines. 


So, the search-binary_handler tries to call the load_binary function and pass linux_binprm 
to it. If the binary handler supports the given executable file format, it starts to prepare the 
executable binary for execution: 


int search_binary_handler(struct linux_binprm *bprm) 


list_for_each_entry(fmt, &formats, lh) { 
retval = fmt->load_binary(bprm); 
if (retval < 0 && !bprm->mm) { 
force_sigsegv(SIGSEGV, current); 
return retval; 


return retval; 


Where the load_binary for example for the elf checks the magic number (each elf binary 
file contains magic number in the header) in the 1inux_bprm buffer (remember that we read 
first 128 bytes from the executable binary file): and exit if itis not elf binary: 


static int load_elf_binary(struct linux_binprm *bprm) 


{ 


loc->elf_ex = *((struct elfhdr *)bprm->buf); 


if (memcmp(elf_ex.e_ident, ELFMAG, SELFMAG) != 0) 
goto out; 


If the given executable file is in elf format, the load_elf_binary continues to execute. The 
load_elf_binary does many different things to prepare on execution executable file. For 
example it checks the architecture and type of the executable file: 


if (loc->elf_ex.e_type != ET_EXEC && loc->elf_ex.e_type != ET_DYN) 
goto out; 

if (!elf_check_arch(&loc->elf_ex) ) 
goto out; 


and exit if there is wrong architecture and executable file non executable non shared. Tries 
to load the program header table : 


elf_phdata = load_elf_phdrs(&loc->elf_ex, bprm->file); 
if (!elf_phdata) 
goto out; 


that describes segments. Read the program interpreter and libraries that linked with the 
our executable binary file from disk and load it to memory. The program interpreter 
specified in the .interp section of the executable file and as you can read in the part that 
describes Linkers itis - /1ib64/1d-linux-x86-64.so.2 forthe x86 64 . It setups the stack 
and map elf binary into the correct location in memory. It maps the bss and the brk 
sections and does many many other different things to prepare executable file to execute. 


In the end of the execution of the load_elf_binary we call the start_thread function and 
pass three arguments to it: 


start_thread(regs, elf_entry, bprm->p); 
retval = 0; 
out: 
kfree(loc); 
out_ret: 
return retval; 


These arguments are: 


e Set of registers for the new task; 
e Address of the entry point of the new task; 
e Address of the top of the stack for the new task. 


As we can understand from the function's name, it starts new thread, but it is not so. The 
start_thread function just prepares new task's registers to be ready to run. Let's look on 
the implementation of this function: 


void 
thread(struct pt_regs *regs, unsigned long new_ip, unsigned long new_sp) 


start_thread_common(regs, new_ip, new_sp, 
USER_CS, __USER_DS, 0); 





As we can see the start_thread function just makes a call of the start_thread_common 
function that will do all for us: 


static void 
start_thread_common(struct pt_regs *regs, unsigned long new_ip, 
unsigned long new_sp, 
unsigned int _cs, unsigned int _ss, unsigned int _ds) 


{ 
loadsegment(fs, 0); 
loadsegment(es, _ds); 
loadsegment(ds, _ds); 
load_gs_index(0); 
regs->ip = new_ip; 
regs->sp = new_sp; 
regs->cs = _CS; 
regs->ss = sy 
regs->flags = X86_EFLAGS_IF; 
force_iret(); 

} 


The start_thread_common function fills fs segment register with zero and es and ds 
with the value of the data segment register. After this we set new values to the instruction 
pointer, cs segments etc. In the end of the start_thread_common function we can see the 

force_iret macro that force a system call return via iret instruction. Ok, we prepared 
new thread to run in userspace and now we can return from the exec_binprm and now we 
are inthe do_execveat_common again. After the exec_binprm will finish its execution we 
release memory for structures that was allocated before and return. 


After we returned from the execve system call handler, execution of our program will be 
started. We can do it, because all context related information already configured for this 
purpose. As we saw the execve system call does not return control to a process, but code, 
data and other segments of the caller process are just overwritten of the program segments. 
The exit from our application will be implemented through the exit system call. 


That's all. From this point our programm will be executed. 


Conclusion 


This is the end of the fourth and last part of the about the system calls concept in the Linux 
kernel. We saw almost all related stuff to the system call concept in these four parts. We 
started from the understanding of the system call concept, we have learned what is it and 
why do users applications need in this concept. Next we saw how does the Linux handle a 
system call from an user application. We met two similar concepts to the system call 
concept, they are vsyscall and vpso and finally we saw how does Linux kernel run an 
user program. 


If you have questions or suggestions, feel free to ping me in twitter OxAX, drop me email or 
just create issue. 


Please note that English is not my first language and I am really sorry for any 
inconvenience. If you found any mistakes please send me PR to linux-insides. 
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How does the open System call work 


Introduction 


This is the fifth part of the chapter that describes system calls mechanism in the Linux 
kernel. Previous parts of this chapter described this mechanism in general. Now | will try to 
describe implementation of different system calls in the Linux kernel. Previous parts from 
this chapter and parts from other chapters of the books describe mostly deep parts of the 
Linux kernel that are faintly visible or fully invisible from the userspace. But the Linux kernel 
code is not only about itself. The vast of the Linux kernel code provides ability to our code. 
Due to the linux kernel our programs can read/write from/to files and don't know anything 
about sectors, tracks and other parts of a disk structures, we can send data over network 
and don't build encapsulated network packets by hand and etc. 


| don't know how about you, but it is interesting to me not only how an operating system 
works, but how do my software interacts with it. As you may know, our programs interacts 
with the kernel through the special mechanism which is called system call. So, I've decided 
to write series of parts which will describe implementation and behavior of system calls 
which we are using every day like read , write , open, close , dup and etc. 


| have decided to start from the description of the open system call. if you have written at 
least one c program, you should know that before we are able to read/write or execute 
other manipulations with a file we need to open it with the open function: 


#include <fcntl.h> 
#include <stdio.h> 
#include <stdlib.h> 
#include <unistd.h> 
#include <sys/stat.h> 
#include <sys/types.h> 


int main(int argc, char *argv) { 
int fd = open("test", O_RDONLY); 


if fd <0 { 
perror("Opening of the file is failed\n"); 
} 
else { 
printf("file sucessfully opened\n"); 
} 
close(fd); 
return 0; 


In this case, the open is the function from standard library, but not system call. The standard 
library will call related system call for us. The open call will return a file descriptor which is 
just a unique number within our process which is associated with the opened file. Now as we 
opened a file and got file descriptor as result of open call, we may start to interact with this 
file. We can write into, read from it and etc. List of opened file by a process is available via 
proc filesystem: 


$ sudo ls /proc/1/fd/ 


9 10 12 14 16 2 21 23 25 27 29 30 32 34 36 38 4 41 43 45 47 49 
50 53 55 58 6 61 63 67 8 
1 11 13 #15 19 20 22 24 26 28 3 31 33 35 37 39 40 42 44 46 48 5 
51 54 57 59 60 62 65 7 9 


| am not going to describe more details about the open routine from the userspace view in 
this post, but mostly from the kernel side. if you are not very familiar with, you can get more 
info in the man page. 


So let's start. 


Definition of the open system call 


If you have read the fourth part of the linux-insides book, you should know that system calls 
are defined with the help of syscALL_DEFINE macro. So, the open system call is not 
exception. 


Definition of the open system call is located in the fs/open.c source code file and looks 


pretty small for the first view: 


SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode) 


{ 
if (force_o_largefile()) 
flags |= O_LARGEFILE; 


return do_sys_open(AT_FDCWD, filename, flags, mode); 


As you may guess, the do_sys_open function from the same source code file does the main 
job. But before this function will be called, let's consider the if clause from which the 
implementation of the open system call starts: 


if (force_o_largefile()) 
flags |= O_LARGEFILE; 


Here we apply the o_LarGEFILE flag to the flags which were passed to open system call in 
a case when the force_o_largefile() will return true. What is o_LARGEFILE ? We may read 
this in the man page for the open(2) system call: 


O_LARGEFILE 


(LFS) Allow files whose sizes cannot be represented in an off_t (but can be represented 


in an off64_t) to be opened. 
As we may read in the GNU C Library Reference Manual: 
off t 


This is a signed integer type used to represent file sizes. In the GNU C Library, this type 
is no narrower than int. If the source is compiled with _FILE_OFFSET_BITS == 64 this 
type is transparently replaced by off64_t. 


and 


off64 t 


This type is used similar to off_t. The difference is that even on 32 bit machines, where 
the off_t type would have 32 bits, off64_t has 64 bits and so is able to address files up 

to 263 bytes in length. When compiling with FILE_OFFSET_BITS == 64 this type is 

available under the name off_t. 


So it is not hard to guess that the off_t , off64 t and o_LARGEFILE are about a file size. 
In the case of the Linux kernel, the o_LARGEFILE is used to disallow opening large files on 

32bit systems if the caller didn't specify o_LARGEFILE flag during opening of a file. On 64bit 
systems we force on this flag in open system call. And the force_o_largefile macro from 
the include/linux/fcntl.h linux kernel header file confirms this: 


#ifndef force_o_largefile 
#define force_o_largefile() (BITS_PER_LONG != 32) 
#endif 


This macro may be architecture-specific as for example for |A-64 architecture, but in our 
case the x86_64 does not provide definition of the force_o_largefile and it will be used 
from include/linux/fentl.h. 


So, as we may see the force_o_largefile is just a macro which expands to the true 

value in our case of x86 64 architecture. As we are considering 64-bit architecture, the 
force_o_largefile will be expanded to true andthe 0_LARGEFILE flag will be added to the 

set of flags which were passed to the open system call. 


Now as we considered meaning of the 0_LARGEFILE flag and force_o_largefile macro, we 
can proceed to the consideration of the implementation of the do_sys_open function. As | 
wrote above, this function is defined in the same source code file and looks: 


long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode) 


struct open_flags op; 
int fd = build_open_flags(flags, mode, &op); 
struct filename *tmp; 


if (fd) 
return fd; 


tmp = getname(filename) ; 
if (IS_ERR(tmp) ) 
return PTR_ERR(tmp); 


fd = get_unused_fd_flags(flags); 
if (fd >= 0) { 
struct file *f = do_filp_open(dfd, tmp, &op); 
if (IS_ERR(f)) { 
put_unused_fd(fd); 
fd = PTR_ERR(f); 
} else { 
fsnotify_open(f); 
fd_install(fd, f); 


} 
putname(tmp); 


return fd; 


Let's try to understand how the do_sys_open works step by step. 


open(2) flags 


As you know the open system call takes set of flags as second argument that control 
opening a file and mode as third argument that specifies permission the permissions of a file 
if itis created. The do_sys_open function starts from the call of the build_open_flags 
function which does some checks that set of the given flags is valid and handles different 
conditions of flags and mode. 


Let's look at the implementation of the build_open_flags . This function is defined in the 
same kernel file and takes three arguments: 


e flags - flags that control opening of a file; 
e mode - permissions for newly created file; 


The last argument - op is represented with the open_flags structure: 


struct open_flags { 
int open_flag; 
umode_t mode; 
int acc_mode; 
int intent; 
int lookup_flags; 
3; 


which is defined in the fs/internal.h header file and as we may see it holds information about 
flags and access mode for internal kernel purposes. As you already may guess the main 
goal of the build_open_flags function is to fill an instance of this structure. 


Implementation of the build_open_flags function starts from the definition of local variables 
and one of them is: 


int acc_mode = ACC_MODE(flags); 


This local variable represents access mode and its initial value will be equal to the value of 
expanded Acc mopE macro. This macro is defined in the include/linux/fs.h and looks pretty 
interesting: 


#define ACC_MODE(x) ("\004\002\006\006"[ (x)&0_ACCMODE] ) 
#define O_ACCMODE 00000003 


The "\004\002\006\006" is an array of four chars: 


"\004\002\006\006" == {'\004', '\002', '\O006', '\006'} 


So, the Acc_MoDE macro just expands to the accession to this array by [(x) & O_ACCMODE] 
index. As we just saw, the o_AccmoDE is oo000003 . By applying x & 0_AccMoDE we will take 
the two least significant bits which are represents read , write Or read/write access 


modes: 
#define O_RDONLY 90000000 
#define O_WRONLY 90000001 
#define O_RDWR 90000002 


After getting value from the array by the calculated index, the acc_mope will be expanded to 
access mode mask of a file which will hold MAY_wRITE , MAY_READ and other information. 


We may see following condition after we have calculated initial access mode: 


if (flags & (O_CREAT | __0_TMPFILE)) 
op->mode = (mode & S_IALLUGO) | S_IFREG; 
else 
op->mode = 0; 


Here we reset permissions in open_flags instance if a opened file wasn't temporary and 
wasn't open for creation. This is because: 


if neither O_CREAT nor O_TMPFILE is specified, then mode is ignored. 


In other case if o_cREAT Or O_TMPFILE were passed we canonicalize it to a regular file 
because a directory should be created with the opendir system call. 


At the next step we check that a file is not tried to be opened via fanotify and without the 
0_CLOEXEC flag: 


flags &= ~FMODE_NONOTIFY & ~O_CLOEXEC; 


We do this to not leak a file descriptor. By default, the new file descriptor is set to remain 
open across an execve system call, but the open system call supports o_cLoexec flag that 
can be used to change this default behaviour. So we do this to prevent leaking of a file 
descriptor when one thread opens a file to set o_cLoexec flag and in the same time the 
second process does a fork) + execve) and as you may remember that child will have copies 
of the parent's set of open file descriptors. 


At the next step we check that if our flags contains o_sync flag, we apply o_psync flag too: 


if (flags & _0 SYNC) 
flags |= O_DSYNC; 


The o_sync flag guarantees that the any write call will not return before all data has been 
transferred to the disk. The o_psync is like o_sync except that there is no requirement to 
wait for any metadata (like atime , mtime and etc.) changes will be written. We apply 

o_psync inacase of _o sync because itis implemented as _ 0 sync|o_psync in the 
Linux kernel. 


After this we must be sure that if a user wants to create temporary file, the flags should 
contain o_TMPFILE_MASK or in other words it should contain or o_CREAT Of O_TMPFILE or 
both and also it should be writeable: 


if (flags & _O_TMPFILE) { 
if ((flags & O_TMPFILE_MASK) != O_TMPFILE) 
return -EINVAL; 
if (!(acc_mode & MAY_WRITE) ) 
return -EINVAL; 
} else if (flags & O_PATH) { 
flags &= O_DIRECTORY | O_NOFOLLOW | O_PATH; 
acc_mode = 0; 


as it is written in in the manual page: 
O_TMPFILE must be specified with one of O_RDWR or O_WRONLY 


If we didn't pass 0o_TMPFILE for creation of a temporary file, we check the o_patH flag at the 
next condition. The o_patH flag allows us to obtain a file descriptor that may be used for 
two following purposes: 


e to indicate a location in the filesystem tree; 
e to perform operations that act purely at the file descriptor level. 


So, in this case the file itself is not opened, but operations like dup ，fcntl and other can 
be used. So, if all file content related operations like read , write and other are permitted, 
Only O_DIRECTORY | O_NOFOLLOW | 0_PATH flags can be used. We have finished with flags for 
this moment in the build_open_flags for this moment and we may fill our open_flags- 
>open_flag with them: 


op->open_flag = flags; 


Now we have filled open_flag field which represents flags that will control opening of a file 
and mode that will represent umask of a new file if we open file for creation. There are still 
to fill last flags in the our open_flags structure. The nextis op->acc_mode which represents 
access mode to a opened file. We already filled the acc_mode local variable with the initial 
value at the beginning of the build_open_flags and now we check last two flags related to 
access mode: 


if (flags & O_TRUNC) 
acc_mode |= MAY_WRITE; 
if (flags & O_APPEND) 
acc_mode |= MAY_APPEND; 
Op->acc_mode = acc_mode; 


These flags are - o_trunc that will truncate an opened file to length o if it existed before 
we open it and the o_appenp flag allows to open a file in append mode . So the opened file 
will be appended during write but not overwritten. 


The next field of the open_flags structure is- intent . It allows us to know about our 
intention or in other words what do we really want to do with file, open it, create, rename it or 
something else. So we set it to zero if our flags contains the o_PATH flag as we can't do 
anything related to a file content with this flag: 


op->intent = flags & O_PATH ? © : LOOKUP_OPEN; 


or just to Lookup_open intention. Additionally we set LookuP_cREATE intention if we want to 
create new file and to be sure that a file didn't exist before with o_exct flag: 


if (flags & O_CREAT) { 
op->intent |= LOOKUP_CREATE; 
if (flags & O_EXCL) 
op->intent |= LOOKUP_EXCL; 


The last flag of the open_flags structure is the lookup_flags : 


if (flags & O_DIRECTORY) 
lookup_flags |= LOOKUP_DIRECTORY; 

if (!(flags & O_NOFOLLOW)) 
lookup_flags |= LOOKUP_FOLLOW; 

op->lookup_flags = lookup_flags; 


return 0; 


We fill it with LooKuP_DIRECTORY if we want to open a directory and Lookup_FoLtow if we don't 
want to follow (open) symlink. That's all. It is the end of the build_open_flags function. The 

open_flags structure is filled with modes and flags for a file opening and we can return back 
to the do_sys_open . 


Actual opening of a file 


At the next step after build_open_flags function is finished and we have formed flags and 
modes for our file we should get the filename structure with the help of the getname 
function by name of a file which was passed to the open system call: 


tmp = getname(filename) ; 
if (IS_ERR(tmp) ) 
return PTR_ERR(tmp); 


The getname function is defined in the fs/namei.c source code file and looks: 


struct filename * 
etname(const char __user * filename) 


return getname_flags(filename, 0, NULL); 


So, it just calls the getname_flags function and returns its result. The main goal of the 
getname_flags function is to copy a file path given from userland to kernel space. The 
filename structure is defined in the include/linux/fs.h linux kernel header file and contains 

following fields: 


e name - pointer to a file path in kernel space; 

e uptr - original pointer from userland; 

e aname - filename from audit context; 

e refcnt - reference counter; 

e iname - a filename in a case when it will be less than PATH_MAX . 


As | already wrote above, the main goal of the getname_flags function is to copy name of a 
file which was passed to the open system call from user space to kernel space with the 
strncpy_from_user function. The next step after a filename will be copied to kernel space is 
getting of new non-busy file descriptor: 


fd = get_unused_fd_flags(flags); 


The get_unused_fd_flags function takes table of open files of the current process, minimum 
( o ) and maximum ( RLIMIT_NOFILE ) possible number of a file descriptor in the system and 
flags that we have passed to the open system call and allocates file descriptor and mark it 
busy in the file descriptor table of the current process. The get_unused_fd_flags function 
sets or clears the o_cLoexec flag depends on its state in the passed flags. 


The last and main step in the do_sys_open is the do_filp_open function: 


struct file *f = do_filp_open(dfd, tmp, &op); 


if (IS ERR(f)) { 
put_unused_fd(fd); 
fd = PTR_ERR(f); 

} else { 
fsnotify_open(f); 
fd_install(fd, f); 


The main goal of this function is to resolve given path name into file structure which 
represents an opened file of a process. If something going wrong and execution of the 
do_filp_open function will be failed, we should free new file descriptor with the 
put_unused_fd Orin other way the file structure returned by the do_filp_open will be 
stored in the file descriptor table of the current process. 


Now let's take a short look at the implementation of the do_filp_open function. This function 
is defined in the fs/namei.c linux kernel source code file and starts from initialization of the 
nameidata structure. This structure will provide a link to a file inode. Actually this is one of 
the main point of the do_filp_open function to acquire an inode by the filename given to 
open system call. After the nameidata structure will be initialized, the path_openat function 
will be called: 


filp = path_openat(&nd, op, flags | LOOKUP_RCU); 


if (unlikely(filp == ERR_PTR(-ECHILD) )) 
filp = path_openat(&nd, op, flags); 
if (unlikely(filp == ERR_PTR(-ESTALE) ) ) 
filp = path_openat(&nd, op, flags | LOOKUP_REVAL); 


Note that it is called three times. Actually, the Linux kernel will open the file in RCU mode. 
This is the most efficient way to open a file. If this try will be failed, the kernel enters the 
normal mode. The third call is relatively rare, only in the nfs file system is likely to be used. 
The path_openat function executes path lookup orin other words it tries to find a dentry 
(what the Linux kernel uses to keep track of the hierarchy of files in directories) 
corresponding to a path. 


The path_openat function starts from the call of the get_empty_flip() function that 
allocates anew file structure with some additional checks like do we exceed amount of 
opened files in the system or not and etc. After we have got allocated new file structure 
we Call the do_tmpfile Or do_o_path functions in a case if we have passed 0_TMPFILE | 


0_CREATE Or 0_PATH flags during call of the open system call. These both cases are quite 
specific, so let's consider quite usual case when we want to open already existed file and 
want to read/write from/to it. 


In this case the path_init function will be called. This function performs some preporatory 
work before actual path lookup. This includes search of start position of path traversal and 
its metadata like inode ofthe path, dentry inode and etc. This can be root directory - 

/ or current directory as in our case, because we use AT_cwpD as Starting point (see call of 
the do_sys_open at the beginning of the post). 


The next step after the path_init is the loop which executes the link_path_walk and 

do_last . The first function executes name resolution or in other words this function starts 
process of walking along a given path. It handles everything step by step except the last 
component of a file path. This handling includes checking of a permissions and getting a file 
component. As a file component is gotten, it is passed to walk_component that updates 
current directory entry from the dcache or asks underlying filesystem. This repeats before 
all path's components will not be handled in such way. After the link_path_walk will be 
executed, the do_last function will populate a file structure based on the result of the 

link_path_walk . As we reached last component of the given file path the vfs_open function 
from the do_last will be called. 


This function is defined in the fs/open.c linux kernel source code file and the main goal of 
this function is to callan open operation of underlying filesystem. 


That's all for now. We didn't consider full implementation of the open system call. We skip 

some parts like handling case when we want to open a file from other filesystem with 

different mount point, resolving symlinks and etc., but it should be not so hard to follow this 

stuff. This stuff does not included in generic implementation of open system call and 

depends on underlying filesystem. If you are interested in, you may lookup the 
file_operations.open callback function for a certain filesystem. 


Conclusion 


This is the end of the fifth part of the implementation of different system calls in the Linux 
kernel. If you have questions or suggestions, ping me on twitter OxAX, drop me an email, or 
just create an issue. In the next part, we will continue to dive into system calls in the Linux 
kernel and see the implementation of the read system call. 


Please note that English is not my first language and I am really sorry for any 
inconvenience. If you find any mistakes please send me PR to linux-insides. 
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定时 器 和 时 钟 管理 


章 介 绍 Linux 内 核 中 定时 器 和 时 钟 管理 相关 的 观念 。 


>t 


e 简介 -简单 介绍 Linux 内 核 中 的 定时 器 。 

e 时 钟 源 框架 简介 - this part describes clocksource framework in the Linux kernel. 

e The tick broadcast framework and dyntick - 介绍 tick broadcast framework and dyntick 
概念 。 

e 定时 器 介绍 - 介绍 Linux 内 核 中 的 定时 器 。 

e Clockevents 框架 简介 - 介绍 另外 一 个 时 钟 管理 相关 的 框架 : clockevents . 

e x86 相关 的 时 钟 源 - 介绍 x86 .64 相关 的 时 钟 源 。 

e Linux 内 核 中 与 时 钟 相 关 的 系统 调用 - 介绍 时 钟 相关 的 系统 调用 。 


Timers and time management in the Linux 
kernel. Part 1. 


Introduction 


This is yet another post that opens new chapter in the linux-insides book. The previous part 
was a list part of the chapter that describes system call concept and now time is to start new 
chapter. As you can understand from the post's title, this chapter will be devoted to the 
timers and time management in the Linux kernel. The choice of topic for the current chapter 
is not accidental. Timers and generally time management are very important and widely 
used in the Linux kernel. The Linux kernel uses timers for various tasks, different timeouts 
for example in TCP implementation, the kernel must know current time, scheduling 
asynchronous functions, next event interrupt scheduling and many many more. 


So, we will start to learn implementation of the different time management related stuff in this 
part. We will see different types of timers and how do different Linux kernel subsystems use 
them. As always we will start from the earliest part of the Linux kernel and will go through 
initialization process of the Linux kernel. We already did it in the special chapter which 
describes initialization process of the Linux kernel, but as you may remember we missed 
some things there. And one of them is the initialization of timers. 


Let's start. 


Initialization of non-standard PC hardware 
clock 


After the Linux kernel was decompressed (more about this you can read in the Kernel 
decompression part) the architecture non-specific code starts to work in the init/main.c 
source code file. After initialization of the lock validator, initialization of cgroups and setting 
canary value we can see the call of the setup_arch function. 


As you may remember this function defined in the arch/x86/kernel/setup.c source code file 
and prepares/initializes architecture-specific stuff (for example it reserves place for bss 
section, reserves place for initrd, parses kernel command line and many many other things). 
Besides this, we can find some time management related functions there. 


The first is: 


x86_init.timers.wallclock_init(); 


We already saw xs6_init structure in the chapter that describes initialization of the Linux 
kernel. This structure contains pointers to the default setup functions for the different 
platforms like Intel MID, Intel CE4100 and etc. The xs6_init structure defined in the 
arch/x86/kernel/x86_init.c and as you can see it determines standard PC hardware by 
default. 


As we can see, the xs6_init structure has xs6_init_ops type that provides a set of 
functions for platform specific setup like reserving standard resources, platform specific 
memory setup, initialization of interrupt handlers and etc. This structure looks like: 


struct x86_init_ops { 


struct x86_init_resources resources; 
struct x86_init_mpparse mpparse; 
struct x86_init_irqs irqs; 
struct x86_init_oem oem; 
struct x86_init_paging paging; 
struct x86_init_timers timers; 
struct x86_init_iommu iommu; 
struct x86_init_pci pci; 


}; 


We can note timers field thathas xs86_init_timers type and as we can understand by its 
name - this field is related to time management and timers. The xs6_init_timers contains 
four fields which are all functions that returns pointer on void: 


e setup percpu clockev - set up the per cpu clock event device for the boot cpu; 
e tsc pre init - platform function called before TSC init; 

e timer_init - initialize the platform timer; 

e wallclock_init - initialize the wallclock device. 


So, as we already know, in our case the wallclock_init executes initialization of the 
wallclock device. If we will look on the xg6_init structure, we will see that wallclock_init 
points to the x86_init_noop : 


struct x86_init_ops x86_init __initdata = { 


.timers = { 
-wallclock_init = x86_init_noop, 


F 


Where the x86_init_noop is just a function that does nothing: 


void _ cpuinit x86_init_noop(void) { } 


for the standard PC hardware. Actually, the wallclock_init function is used in the Intel MID 
platform. Initialization of the x86_init.timers.wallclock_init located in the 
arch/x86/platform/intel-mid/intel-mid.c source code file in the x86_intel_mid_early_setup 
function: 





void __init x86_intel_mid_early_setup(void) 


{ 


x86_init.timers.wallclock_init = intel_mid_rtc_init; 


Implementation of the intel_mid_rtc_init function is in the arch/x86/platform/intel- 

mid/intel_mid_vrtc.c source code file and looks pretty easy. First of all, this function parses 

Simple Firmware Interface M-Real-Time-Clock table for the getting such devices to the 
sfi_mrtc_array array and initialization of the set_time and get_time functions: 


void __init intel_mid_rtc_init(void) 
{ 


unsigned long vrtc_paddr; 

sfi_table_parse(SFI_SIG_MRTC, NULL, NULL, sfi_parse_mrtc); 
vrtc_paddr = sfi_mrtc_array[0].phys_addr; 

if (!sfi_mrtc_num || !vrtc_paddr) 


return; 


vrtc_virt_base = (void __iomem *)set_fixmap_offset_nocache(FIX_LNW_VRTC, 





vrtc_paddr); 


x86_platform.get_wallclock = vrtc_get_time; 


x86_platform.set_wallclock = vrtc_set_mmss; 


That's all, after this a device based on Intel mip will be able to get time from hardware 

clock. As | already wrote, the standard PC x86_64 architecture does not support 
x86_init_noop and just do nothing during call of this function. We just saw initialization of 

the real time clock for the Intel MID architecture and now times to return to the general 
x86_64 architecture and will look on the time management related stuff there. 


Acquainted with jiffies 


If we will return to the setup_arch function which is located as you remember in the 
arch/x86/kernel/setup.c source code file, we will see the next call of the time management 
related function: 


register_refined_jiffies(CLOCK_TICK_RATE); 


Before we will look on the implementation of this function, we must know about jiffy. As we 
can read on wikipedia: 


Jiffy is an informal term for any unspecified short period of time 


This definition is very similar to the jiffy in the Linux kernel. There is global variable with 
the jiffies which holds the number of ticks that have occurred since the system booted. 
The Linux kernel sets this variable to zero: 


extern unsigned long volatile _jiffy_data jiffies; 


during initialization process. This global variable will be increased each time during timer 
interrupt. Besides this, near the jiffies variable we can see definition of the similar 
variable 


extern u64 jiffies_64; 


Actually only one of these variables is in use in the Linux kernel. And it depends on the 
processor type. For the x86 64 it will be u64 use and for the x86 is unsigned long . We will 
see this if we will look on the arch/x86/kernel/vmlinux.lds.S linker script: 


#ifdef CONFIG_X86_32 
erie = jiffies_64; 
slg 
人 = jiffies; 
vendif 
In the case of x86 32 the jiffies willbe lower 32 bits ofthe jiffies_64 variable. 
Schematically, we can imagine it as follows 


jiffies_64 
idm Se demo Sas Sos Seen eee AAAA + 
| | | 
| | | 
| | jiffies on `x86_32` | 
| | | 
| | | 
本 十 
63 31 0 


Now we know alittle theory about jiffies and we can return to the our function. There is 
no architecture-specific implementation for our function - the register_refined_jiffies . 
This function located in the generic kernel code - kernel/time/jiffies.c source code file. Main 
point of the register_refined_jiffies is registration of the jiffy clocksource . Before we will 
look on the implementation of the register_refined_jiffies function, we must know what is 
it clocksource . AS we can read in the comments: 


The ~clocksource’ is hardware abstraction for a free-running counter. 


I'm not sure about you, but that description didn't give a good understanding about the 

clocksource concept. Let's try to understand what is it, but we will not go deeper because 
this topic will be described in a separate part in much more detail. The main point of the 

clocksource Is timekeeping abstraction or in very simple words - it provides a time value to 
the kernel. We already know about jiffies interface that represents number of ticks that 
have occurred since the system booted. It represented by the global variable in the Linux 
kernel and increased each timer interrupt. The Linux kernel can use jiffies for time 
measurement. So why do we need in separate context like the clocksource ? Actually 
different hardware devices provide different clock sources that are widely in their 
capabilities. The availability of more precise techniques for time intervals measurement is 
hardware-dependent. 


For example x86 has on-chip a 64-bit counter that is called Time Stamp Counter and its 
frequency can be equal to processor frequency. Or for example High Precision Event Timer 
that consists of a 64-bit counter of atleast 10 MHz frequency. Two different timers and 
they are both for xse . If we will add timers from other architectures, this only makes this 
problem more complex. The Linux kernel provides clocksource concept to solve the 
problem. 


The clocksource concept represented by the clocksource structure in the Linux kernel. This 
structure defined in the include/linux/clocksource.h header file and contains a couple of 
fields that describe a time counter. For example it contains - name field which is the name of 
a counter, flags field that describes different properties of a counter, pointers to the 

suspend and resume functions, and many more. 


Let's look on the clocksource structure for jiffies that defined in the kernel/time/jiffies.c 
source code file: 


static struct clocksource clocksource_jiffies = { 


.name = "jiffies", 

.rating = 1, 

.read = jiffies_read, 

.mask SOPINEET E 

.mult = NSEC_PER_JIFFY << JIFFIES_SHIFT, 
. Shift = JIFFIES_SHIFT, 

.max_cycles = 10, 


We can see definition of the default name here - jiffies , the nextis rating field allows 
the best registered clock source to be chosen by the clock source management code 
available for the specified hardware. The rating may have following value: 


e 1-99 - Only available for bootup and testing purposes; 
e 100-199 - Functional for real use, but not desired. 


e 200-299 -Acorrect and usable clocksource. 
e 300-399 - A reasonably fast and accurate clocksource. 
e 400-499 - The ideal clocksource. A must-use where available; 


For example rating of the time stamp counter is 300 , but rating of the high precision event 
timer is 250 . The next field is read -is pointer to the function that allows to read 
clocksource's cycle value or in other words it just returns jiffies variable with cycle_t 


type: 


static cycle_t jiffies_read(struct clocksource *cs) 


{ 


return (cycle_t) jiffies; 


that is just 64-bit unsigned type: 


typedef u64 cycle_t; 


The next field is the mask value ensures that subtraction between counters values from non 
64 bit counters do not need special overflow logic. In our case the mask is oxffffffff 
and itis 32 bits. This means that jiffy wraps around to zero after 42 seconds: 


>>> QOxffffffff 
4294967295 

>>> 42 * pow(10, -9) 
4.2000000000000006e- 08 


anoseconds 
anosecon 


>>> 43 * pow(10, -9) 
4.3e-08 


The next two fields mult and shift are used to convert the clocksource's period to 
nanoseconds per cycle. When the kernel calls the clocksource.read function, this function 
returns value in machine time units represented with cycle_t data type that we saw just 
now. To convert this return value to the nanoseconds we need in these two fields: mult and 

shift . The clocksource provides clocksource_cyc2ns function that will do it for us with the 
following expression: 


((u64) cycles * mult) >> shift; 


As we can see the mult field is equal: 


Ke A 
间 人 


NSEC_PER_JIFFY << JIFFIES_SHIFT 


#define NSEC_PER_JIFFY ((NSEC_PER_SEC+HZ/2)/HZ) 
#define NSEC_PER_SEC 1000000000L 


by default, andthe shift is 


#if HZ < 34 

#define JIFFIES_SHIFT 6 
#elif HZ < 67 

#define JIFFIES_SHIFT 7 
#else 

#define JIFFIES_SHIFT 8 
#endif 


The jiffies clock source uses the nsec_PER_JIFFY multiplier conversion to specify the 
nanosecond over cycle ratio. Note that values of the JIFFIES_SHIFT and NSEC_PER_JIFFY 
depend on uz value. The Hz represents the frequency of the system timer. This macro 
defined in the include/asm-generic/param.h and depends on the coNFIG_Hz kernel 
configuration option. The value of Hz differs for each supported architecture, but for x86 
it's defined like: 


#define HZ CONFIG_HZ 


Where coNFIG_Hz can be one of the following values: 


Terminal 


File Edit View Search Terminal Help 


Timer frequency 
Use the arrow keys to navigate this window or press the 
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BAR>. Press <?> for additional information about this 





424 


This means that in our case the timer interrupt frequency is 250 Hz oroccurs 250 times 
per second or one timer interrupt each 4ms . 


The last field that we can see in the definition of the clocksource_jiffies structure is the - 
max_cycles that holds the maximum cycle value that can safely be multiplied without 
potentially causing an overflow. 


Ok, we just saw definition of the ‘clocksource_ jiffies structure, also we know a litt 
le about “jiffies~ and ~clocksource’, now is time to get back to the implementation of 
the our function. In the beginning of this part we have stopped on the call of the: 


register_refined_jiffies(CLOCK_TICK_RATE); 


function from the arch/x86/kernel/setup.c source code file. 


As | already wrote, the main purpose of the register_refined_jiffies function is to register 

refined_jiffies clocksource. We already saw the clocksource_jiffies structure 
represents standard jiffies clock source. Now, if you look in the kernel/time/jiffies.c 
source code file, you will find yet another clock source definition: 


struct clocksource refined_jiffies; 


There is one different between refined_jiffies and clocksource_jiffies : The standard 
jiffies based clock source is the lowest common denominator clock source which should 

function on all systems. As we already know, the jiffies global variable will be increased 

during each timer interrupt. This means that standard jiffies based clock source has the 

same resolution as the timer interrupt frequency. From this we can understand that standard 
jiffies based clock source may suffer from inaccuracies. The refined_jiffies uses 
CLOCK_TICK_RATE as the base of jiffies shift. 


Let's look on the implementation of this function. First of all we can see that the 
refined_jiffies clock source based on the clocksource_jiffies structure: 


int register_refined_jiffies(long cycles_per_second) 


u64 nsec_per_tick, shift_hz; 
long cycles_per_tick; 


refined_jiffies = clocksource_jiffies; 
refined_jiffies.name = "refined-jiffies"; 
refined_jiffies.rating++; 


Here we can see that we update the name of the refined_jiffies to refined-jiffies and 

increase the rating of this structure. As you remember, the clocksource_jiffies has rating - 
1 ,SoOoOur refined_jiffies clocksource will have rating - 2 . This means that the 
refined_jiffies will be best selection for clock source management code. 


In the next step we need to calculate number of cycles per one tick: 


cycles_per_tick = (cycles_per_second + HZ/2)/HZ; 


Note that we have used NsEc PER SsEc macro as the base of the standard jiffies 
multiplier. Here we are using the cycles_per_second which is the first parameter of the 
register_refined_jiffies function. We've passed the cLock_TICK_RATE macro to the 
register_refined_jiffies function. This macro definied in the arch/x86/include/asm/timex.h 
header file and expands to the: 


#define CLOCK_TICK_RATE PIT_TICK_RATE 


where the pIT_TICK_RATE macro expands to the frequency of the Intel 8253: 


#define PIT_TICK_RATE 1193182ul 


After this we calculate shift_hz forthe register_refined_jiffies that will store hz << 8 
or in other words frequency of the system timer. We shift left the cycles_per_second or 
frequency of the programmable interval timer on 8 in order to get extra accuracy: 


shift_hz = (u64)cycles_per_second << 8; 
shift_hz += cycles_per_tick/2; 
do_div(shift_hz, cycles_per_tick); 


In the next step we calculate the number of seconds per one tick by shifting left the 
NSEC_PER_SEC On 8 too as we did it with the shift_hz and do the same calculation as 
before: 


nsec_per_tick = (u64)NSEC_PER_SEC << 8; 
nsec_per_tick += (u32)shift_hz/2; 
do_div(nsec_per_tick, (u32)shift_hz); 


refined_jiffies.mult = ((u32)nsec_per_tick) << JIFFIES_SHIFT; 


In the end of the _register_refined_jiffies function we register new clock source with the 
__clocksource_register function that defined in the include/linux/clocksource.h header file 
and return: 


__clocksource_register(&refined_jiffies); 
return o; 


The clock source management code provides the API for clock source registration and 

selection. As we can see, clock sources are registered by calling the 
__clocksource_register function during kernel initialization or from a kernel module. During 
registration, the clock source management code will choose the best clock source available 
in the system using the clocksource.rating field which we already saw when we initialized 
clocksource structure for jiffies . 


Using the jiffies 


We just saw initialization of two jiffies based clock sources in the previous paragraph: 


e standard jiffies based clock source; 
e refined jiffies based clock source; 


Don't worry if you don't understand the calculations here. They look frightening at first. Soon, 
step by step we will learn these things. So, we just saw initialization of jffies based clock 
sources and also we know that the Linux kernel has the global variable jiffies that holds 
the number of ticks that have occurred since the kernel started to work. Now, let's look how 
to use it. Touse jiffies We just can use jiffies global variable by its name or with the 
call of the get_jiffies_64 function. This function defined in the kernel/time/jiffies.c source 
code file and just returns full 64-bit value of the jiffies : 


u64 get_jiffies_64(void) 


unsigned long seq; 
u64 ret; 


read_seqbegin(&jiffies_lock); 
ret jiffies_64; 
} while (read_seqretry(&jiffies_lock, seq)); 
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return ret; 


} 
EXPORT_SYMBOL(get_jiffies_64); 


Note that the get_jiffies_64 function does not implemented as jiffies_read for example: 


static cycle_t jiffies_read(struct clocksource *cs) 


{ 


return (cycle_t) jiffies; 


We can see that implementation of the get_jiffies_64 is more complex. The reading of the 
jiffies_64 variable is implemented using seqlocks. Actually this is done for machines that 
cannot atomically read the full 64-bit values. 


If we can access the jiffies orthe jiffies_64 variable we can convert it to human time 
units. To get one second we can use following expression: 


jiffies / HZ 


So, if we know this, we can get any time units. For example: 


/ Inirty seconas Trom nov 


jiffies + 30*HZ 


/ Two minutes om now f 


jiffies + 120*HZ 


/ vne Witt 1Seconc ron NOW 


jiffies + HZ / 1000 


That's all. 


Conclusion 


This concludes the first part covering time and time management related concepts in the 
Linux kernel. We met first two concepts and its initialization in this part: jiffies and 

clocksource . In the next part we will continue to dive into this interesting theme and as | 
already wrote in this part we will acquainted and try to understand insides of these and other 
time management concepts in the Linux kernel. 


If you have questions or suggestions, feel free to ping me in twitter OxAX, drop me email or 
just create issue. 


Please note that English is not my first language and | am really sorry for any 
inconvenience. If you found any mistakes please send me PR to linux-insides. 
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Timers and time management in the Linux 
kernel. Part 2. 


Introduction to the clocksource framework 


The previous part was the first part in the current chapter that describes timers and time 
management related stuff in the Linux kernel. We got acquainted with two concepts in the 
previous part: 


© jiffies 


@ clocksource 


The first is the global variable that is defined in the include/linux/jiffies.n header file and 
represents the counter that is increased during each timer interrupt. So if we can access this 

global variable and we know the timer interrupt rate we can convert jiffies to the human 

time units. As we already know the timer interrupt rate represented by the compile-time 

constant that is called Hz in the Linux kernel. The value of Hz is equal to the value of the 
CONFIG_HZ kernel configuration option and if we will look into the 

arch/x86/configs/x86_64 defconfig kernel configuration file, we will see that: 


CONFIG_HZ_1000=y 


kernel configuration option is set. This means that value of coNFIG_HZ will be 1000 by 
default for the x86 64 architecture. So, if we divide the value of jiffies by the value of 
HZ : 


jiffies / HZ 


we will get the amount of seconds that elapsed since the beginning of the moment the Linux 
kernel started to work or in other words we will get the system uptime. Since Hz represents 
the amount of timer interrupts in a second, we can set a value for some time in the future. 
For example: 


unsigned long later = jiffies + 60*HZ; 


unsigned long later = jiffies + 5*60*HZ; 


This is a very common practice in the Linux kernel. For example, if you will look into the 
arch/x86/kernel/smpboot.c source code file, you will find the do_boot_cpu function. This 
function boots all processors besides bootstrap processor. You can find a snippet that waits 
ten seconds for a response from the application processor: 


if (!boot_error) { 
timeout = jiffies + 10*HZ; 
while (time_before(jiffies, timeout)) { 


udelay(100); 


We assign jiffies + 10*Hz value tothe timeout variable here. As | think you already 
understood, this means a ten seconds timeout. After this we are entering a loop where we 
use the time_before macro to compare the current jiffies value and our timeout. 


Or for example if we look into the sound/isa/sscape.c source code file which represents the 
driver for the Ensoniq Soundscape Elite sound card, we will see the obp_startup_ack 
function that waits upto a given timeout for the On-Board Processor to return its start-up 
acknowledgement sequence: 


static int obp_startup_ack(struct soundscape *s, unsigned timeout) 
{ 


unsigned long end_time = jiffies + msecs_to_jiffies(timeout ); 


do { 


x = host_read_unsafe(s->io_base); 


if (x == Oxfe || x == Oxff) 
return 1; 
msleep(10); 
} while (time_before(jiffies, end_time)); 


return ©: 


As you can see, the jiffies variable is very widely used in the Linux kernel code. As | 
already wrote, we met yet another new time management related concept in the previous 
part - clocksource . We have only seen a short description of this concept and the API for a 
clock source registration. Let's take a closer look in this part. 


Introduction to clocksource 


The clocksource concept represents the generic API for clock sources management in the 
Linux kernel. Why do we need a separate framework for this? Let's go back to the 
beginning. The time concept is the fundamental concept in the Linux kernel and other 
operating system kernels. And the timekeeping is one of the necessities to use this concept. 
For example Linux kernel must know and update the time elapsed since system startup, it 
must determine how long the current process has been running for every processor and 
many many more. Where the Linux kernel can get information about time? First of all it is 
Real Time Clock or RTC that represents by the a nonvolatile device. You can find a set of 
architecture-independent real time clock drivers in the Linux kernel in the drivers/rtc 
directory. Besides this, each architecture can provide a driver for the architecture-dependent 
real time clock, for example - cmos/rtc - arch/x86/kernel/rtc.c for the x86 architecture. The 
second is system timer - timer that excites interrupts with a periodic rate. For example, for 
IBM PC compatibles it was - programmable interval timer. 


We already know that for timekeeping purposes we can use jiffies in the Linux kernel. 
The jiffies can be considered as read only global variable which is updated with Hz 
frequency. We know that the Hz is a compile-time kernel parameter whose reasonable 
range is from 100 to 1000 Hz. So, it is guaranteed to have an interface for time 
measurement with 1 - 10 milliseconds resolution. Besides standard jiffies , we saw 
the refined_jiffies clock source in the previous part that is based on the i8253/i8254 
programmable interval timer tick rate which is almost 1193182 hertz. So we can get 
something about 1 microsecond resolution with the refined_jiffies . In this time, 
nanoseconds are the favorite choice for the time value units of the given clock source. 


The availability of more precise techniques for time intervals measurement is hardware- 
dependent. We just knew a little about x86 dependent timers hardware. But each 
architecture provides own timers hardware. Earlier each architecture had own 
implementation for this purpose. Solution of this problem is an abstraction layer and 
associated API in a common code framework for managing various clock sources and 
independent of the timer interrupt. This common code framework became - clocksource 
framework. 


Generic timeofday and clock source management framework moved a lot of timekeeping 
code into the architecture independent portion of the code, with the architecture-dependent 
portion reduced to defining and managing low-level hardware pieces of clocksources. It 
takes a large amount of funds to measure the time interval on different architectures with 
different hardware, and it is very complex. Implementation of the each clock related service 
is strongly associated with an individual hardware device and as you can understand, it 
results in similar implementations for different architectures. 


Within this framework, each clock source is required to maintain a representation of time as 
a monotonically increasing value. As we can see in the Linux kernel code, nanoseconds are 
the favorite choice for the time value units of a clock source in this time. One of the main 
point of the clock source framework is to allow an user to select clock source among a range 
of available hardware devices supporting clock functions when configuring the system and 
selecting, accessing and scaling different clock sources. 


The clocksource structure 


The fundamental of the clocksource framework is the clocksource structure that defined in 
the include/linux/clocksource.h header file. We already saw some fields that are provided by 
the clocksource structure in the previous part. Let's look on the full definition of this 
structure and try to describe all of its fields: 


struct clocksource { 
cycle_t (*read)(struct clocksource *cs); 
cycle_t mask; 
u32 mult; 
u32 shift; 
u64 max_idle_ns; 
u32 maxadj; 
#ifdef CONFIG_ARCH_CLOCKSOURCE_DATA 
struct arch_clocksource_data archdata; 
#endif 
u64 max_cycles; 
const char *name; 
struct list_head list; 
int rating; 
int (*enable)(struct clocksource *cs); 
void (*disable)(struct clocksource *cs); 
unsigned long flags; 
void (*suspend)(struct clocksource *cs); 
void (*resume)(struct clocksource *cs); 
#ifdef CONFIG_CLOCKSOURCE_WATCHDOG 
struct list_head wd_list; 
cycle_t cs_last; 
cycle_t wd_last; 
#endif 
struct module *owner; 
} ____cacheline_aligned; 


We already saw the first field of the clocksource structure in the previous part - it is pointer 
to the read function that returns best counter selected by the clocksource framework. For 
example we use jiffies_read function to read jiffies value: 


static struct clocksource clocksource_jiffies = { 


.read = jiffies_read, 


where jiffies_read just returns: 


static cycle t jiffies_read(struct clocksource *cs) 


{ 


return (cycle_t) jiffies; 


Orthe read_tsc function: 


static struct clocksource clocksource_tsc = { 


. read = read_tsc, 


for the time stamp counter reading. 


The next field is mask that allows to ensure that subtraction between counters values from 
non 64 bit counters do not need special overflow logic. After the mask field, we can see 
two fields: mult and shift . These are the fields that are base of mathematical functions 
that are provide ability to convert time values specific to each clock source. In other words 
these two fields help us to convert an abstract machine time units of a counter to 
nanoseconds. 


After these two fields we can see the 64 bits max_idle_ns field represents max idle time 
permitted by the clocksource in nanoseconds. We need in this field for the Linux kernel with 
enabled coNFIG_No_Hz kernel configuration option. This kernel configuration option enables 
the Linux kernel to run without a regular timer tick (we will see full explanation of this in other 
part). The problem that dynamic tick allows the kernel to sleep for periods longer than a 
single tick, moreover sleep time could be unlimited. The max_idle_ns field represents this 
sleeping limit. 


The next field after the max_idle_ns is the maxadj field which is the maximum adjustment 
value to mult . The main formula by which we convert cycles to the nanoseconds: 


((u64) cycles * mult) >> shift; 


is not 100% accurate. Instead the number is taken as close as possible to a nanosecond 
and maxadj helps to correct this and allows clocksource API to avoid mult values that 
might overflow when adjusted. The next four fields are pointers to the function: 


e enable - optional function to enable clocksource; 
e disable - optional function to disable clocksource; 
e suspend - suspend function for the clocksource; 

e resume -resume function for the clocksource; 


The next field is the max_cycles and as we can understand from its name, this field 
represents maximum cycle value before potential overflow. And the last field is owner 
represents reference to a kernel module that is owner of a clocksource. This is all. We just 
went through all the standard fields of the clocksource structure. But you can noted that we 
missed some fields of the clocksource structure. We can divide all of missed field on two 
types: Fields of the first type are already known for us. For example, they are name field 


that represents name of a clocksource , the rating field that helps to the Linux kernel to 
select the best clocksource and etc. The second type, fields which are dependent from the 
different Linux kernel configuration options. Let's look on these fields. 


The first field is the archdata . This field has arch_clocksource_data type and depends on 
the CONFIG_ARCH_CLOCKSOURCE_DATA kernel configuration option. This field is actual only for the 
x86 and IA64 architectures for this moment. And again, as we can understand from the 
field's name, it represents architecture-specific data for a clock source. For example, it 
represents vpso clock mode: 


struct arch_clocksource_data { 
int vclock_mode; 


}; 


forthe x86 architectures. Where the vpso clock mode can be one of the: 


#define VCLOCK_NONE 0 
#define VCLOCK_TSC 1 
#define VCLOCK_HPET 2 
#define VCLOCK_PVCLOCK 3 


The last three fields are wd list , cs_last andthe wd_last depends on the 
CONFIG_CLOCKSOURCE_WATCHDoG kernel configuration option. First of all let's try to understand 
what is it watchdog . In a simple words, watchdog is a timer that is used for detection of the 

computer malfunctions and recovering from it. All of these three fields contain watchdog 
related data that is used by the clocksource framework. If we will grep the Linux kernel 
source code, we will see that only arch/x86/KConfig kernel configuration file contains the 

CONFIG_CLOCKSOURCE_WATCHDoG kernel configuration option. So, why do xs6 and x86 64 
need in watchdog? You already may know that all x86 processors has special 64-bit 
register - time stamp counter. This register contains number of cycles since the reset. 
Sometimes the time stamp counter needs to be verified against another clock source. We 
will not see initialization of the watchdog timer in this part, before this we must learn more 
about timers. 


That's all. From this moment we know all fields of the clocksource structure. This 
knowledge will help us to learn insides of the clocksource framework. 


New clock source registration 


We saw only one function from the clocksource framework in the previous part. This 
function was - __clocksource_register . This function defined in the 
include/linux/clocksource.h header file and as we can understand from the function's name, 
main point of this function is to register new clocksource. If we will look on the 
implementation of the _ clocksource_register function, we will see that it just makes call of 
the _clocksource_register_scale function and returns its result: 


static inline int __clocksource_register(struct clocksource *cs) 


{ 


return __clocksource_register_scale(cs, i, 0); 


Before we will see implementation of the _clocksource_register_scale function, we can 
see that clocksource provides additional API for a new clock source registration: 


static inline int clocksource_register_hz(struct clocksource *cs, u32 hz) 
{ 

return __clocksource_register_scale(cs, i, hz); 
} 
static inline int clocksource_register_khz(struct clocksource *cs, u32 khz) 
{ 

return __clocksource_register_scale(cs, 1000, khz); 
} 


And all of these functions do the same. They return value of the 
__clocksource_register_scale function but with different set of parameters. The 
__clocksource_register_scale function defined in the kernel/time/clocksource.c source code 

file. To understand difference between these functions, let's look on the parameters of the 
clocksource_register_khz function. As we can see, this function takes three parameters: 


e cs -clocksource to be installed; 

e scale -Scale factor of a clock source. In other words, if we will multiply value of this 
parameter on frequency, we will get hz of a clocksource; 

e freq - clock source frequency divided by scale. 


Now let's look on the implementation of the _ clocksource_register_scale function: 


int __clocksource_register_scale(struct clocksource *cs, u32 scale, u32 freq) 


{ 


__clocksource_update_freq_scale(cs, scale, freq); 
mutex_lock(&clocksource_mutex) ; 
clocksource_enqueue(cs); 
clocksource_enqueue_watchdog(cs); 
clocksource_select(); 
mutex_unlock(&clocksource_mutex) ; 

return 0; 


First of all we can see that the _ clocksource_register_scale function starts from the call of 
the _ clocksource update freq_scale function that defined in the same source code file and 
updates given clock source with the new frequency. Let's look on the implementation of this 
function. In the first step we need to check given frequency and if it was not passed as 

zero , we need to calculate mult and shift parameters for the given clock source. Why 
do we need to check value of the frequency ? Actually it can be zero. if you attentively 
looked on the implementation of the _ clocksource_register function, you may have noticed 
that we passed frequency as o .We will do it only for some clock sources that have self 
defined mult and shift parameters. Look in the previous part and you will see that we 
saw calculation of the mult and shift for jiffies . The 

__clocksource_update_freq_scale function will do it for us for other clock sources. 


So in the start of the _ clocksource_update_freq_scale function we check the value of the 
frequency parameter and if is not zero we need to calculate mult and shift for the given 
clock source. Let's look on the mult and shift calculation: 


void __clocksource_update_freq_scale(struct clocksource *cs, u32 scale, u32 freq) 


{ 


u64 sec; 


if (freq) { 
sec = cs->mask; 
do_div(sec, freq); 
do_div(sec, scale); 


if (!sec) 
sec = 1; 

else if (sec > 600 && cs->mask > UINT_MAX) 
sec = 600; 


clocks_calc_mult_shift(&cs->mult, &cs->shift, freq, 
NSEC_PER_SEC / scale, sec * scale); 


Here we can see calculation of the maximum number of seconds which we can run before a 
clock source counter will overflow. First of all we fill the sec variable with the value of a 
clock source mask. Remember that a clock source's mask represents maximum amount of 
bits that are valid for the given clock source. After this, we can see two division operations. 
At first we divide our sec variable on a clock source frequency and then on scale factor. 
The freq parameter shows us how many timer interrupts will be occurred in one second. 
So, we divide mask value that represents maximum number of a counter (for example 
jiffy ) on the frequency of a timer and will get the maximum number of seconds for the 
certain clock source. The second division operation will give us maximum number of 
seconds for the certain clock source depends on its scale factor which can be 1 hertz or 
1 kilohertz (10^ Hz). 


After we have got maximum number of seconds, we check this value and set itto 1 or 

600 depends on the result at the next step. These values is maximum sleeping time for a 
clocksource in seconds. In the next step we can see call of the clocks_calc_mult_shift . 
Main point of this function is calculation of the mult and shift values for a given clock 
source. In the end of the _ clocksource_update_freq_scale function we check that just 
calculated mult value of a given clock source will not cause overflow after adjustment, 
update the max_idle_ns and max_cycles values of a given clock source with the maximum 
nanoseconds that can be converted to a clock source counter and print result to the kernel 
buffer: 


pr_info("%s: mask: Ox%]llx max_cycles: Ox%llx, max_idle_ns: %lld ns\n", 
cs->name, cs->mask, cs->max_cycles, cs->max_idle_ns); 


that we can see in the dmesg output: 


$ dmesg | grep "clocksource:" 

[ 0.000000] clocksource: refined-jiffies: mask: Oxffffffff max_cycles: OxfffffffFf, 
max_idle_ns: 1910969940391419 ns 

[ 0.000000] clocksource: hpet: mask: Oxffffffff max_cycles: Oxffffffff, max_idle_ns 
: 133484882848 ns 

[ 0.094084] clocksource: jiffies: mask: Oxffffffff max_cycles: Oxffffffff, max_idle 
_ns: 1911260446275000 ns 


[ 0.205302] clocksource: acpi_pm: mask: Oxffffff max_cycles: Oxffffff, max_idle_ns: 
2085701024 ns 


[ 1.452979] clocksource: tsc: mask: QOxffffffffffffffff max_cycles: 0x7350b459580, m 
ax_idle_ns: 881591204237 ns 


After the _ clocksource_update_freq_scale function will finish its work, we can return back to 
the _ clocksource_register_scale function that will register new clock source. We can see 
the call of the following three functions: 


mutex_lock(&clocksource_mutex); 
clocksource_enqueue(cs); 
clocksource_enqueue_watchdog(cs); 
clocksource_select(); 
mutex_unlock(&clocksource_mutex) ; 


Note that before the first will be called, we lock the clocksource_mutex mutex. The point of 
the clocksource_mutex mutex is to protect curr_clocksource variable which represents 
currently selected clocksource and clocksource_list variable which represents list that 
contains registered clocksources . Now, let's look on these three functions. 


The first clocksource_enqueue function and other two defined in the same source code file. 
We go through all already registered clocksources or in other words we go through all 
elements of the clocksource_list and tries to find best place for a given clocksource : 


static void clocksource_enqueue(struct clocksource *cs) 


{ 


struct list_head *entry = &clocksource_list; 
struct clocksource *tmp; 


list_for_each_entry(tmp, &clocksource_list, list) 
if (tmp->rating >= cs->rating) 
entry = &tmp->list; 
list_add(&cs->list, entry); 


In the end we just insert new clocksource to the clocksource_list . The second function - 

clocksource_enqueue_watchdog does almost the same that previous function, but it inserts 
new clock source to the wd_list depends on flags of a clock source and starts new 
watchdog timer. As | already wrote, we will not consider watchdog related stuff in this part 
but will do it in next parts. 


The last function is the clocksource_select . AS we can understand from the function's 
name, main point of this function - select the best clocksource from registered 
clocksources. This function consists only from the call of the function helper: 


static void clocksource_select(void) 


{ 


return __clocksource_select(false); 


Note that the __clocksource_select function takes one parameter ( false in our case). This 
bool parameter shows how to traverse the clocksource_list . In our case we pass false 
that is meant that we will go through all entries of the clocksource_list . We already know 
that clocksource with the best rating will the first in the clocksource_list after the call of 
the clocksource_enqueue function, so we can easily get it from this list. After we found a 
clock source with the best rating, we switch to it: 


if (curr_clocksource != best && !timekeeping_notify(best)) { 
pr_info("Switched to clocksource %s\n", best->name); 


curr_clocksource = best; 


The result of this operation we can see in the dmesg output: 


$ dmesg | grep Switched 
[ 0.199688] clocksource: Switched to clocksource hpet 
[ 2.452966] clocksource: Switched to clocksource tsc 


Note that we can see two clock sources in the dmesg output ( hpet and tsc in our case). 
Yes, actually there can be many different clock sources on a particular hardware. So the 
Linux kernel knows about all registered clock sources and switches to a clock source with a 
better rating each time after registration of a new clock source. 


If we will look on the bottom of the kernel/time/clocksource.c source code file, we will see 
that it has sysfs interface. Main initialization occurs in the init_clocksource_sysfs function 
which will be called during device initcalls . Let's look on the implementation of the 


init_clocksource_sysfs function: 


static struct bus_type clocksource_subsys = { 
.name = "clocksource", 
.dev_name = "clocksource", 


}; 


static int _init init_clocksource_sysfs(void) 


{ 


int error = subsys_system_register(&clocksource_subsys, NULL); 


if (!error) 
error = device register(&device clocksource); 
if (!error) 
error = device_create_file( 
&device_clocksource, 
&dev_attr_current_clocksource); 
if (!error) 
error = device_create_file(&device_clocksource, 
&dev_attr_unbind_clocksource) ; 
if (!error) 
error = device_create_file( 
&device_clocksource, 
&dev_attr_available_clocksource); 
return error; 


} 


device_initcall(init_clocksource_sysfs); 


First of all we can see that it registers a clocksource Subsystem with the call of the 
subsys_system_register function. In other words, after the call of this function, we will have 


following directory: 


$ pwd 
/sys/devices/system/clocksource 


After this step, we can see registration of the device_clocksource device which is 
represented by the following structure: 


static struct device device_clocksource = { 
.id = 0, 
.bus = &clocksource_subsys, 


}; 


and creation of three files: 


@ dev attr current clocksource 
e dev_attr_unbind_clocksource 


@ dev_attr_available_clocksource 


These files will provide information about current clock source in the system, available clock 
sources in the system and interface which allows to unbind the clock source. 


After the init_clocksource_sysfs function will be executed, we will be able find some 
information about available clock sources in the: 


$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
tsc hpet acpi_pm 


Or for example information about current clock source in the system: 


$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
tsc 


In the previous part, we saw API for the registration of the jiffies clock source, but didn't 
dive into details about the clocksource framework. In this part we did it and saw 
implementation of the new clock source registration and selection of a clock source with the 
best rating value in the system. Of course, this is not all API that clocksource framework 
provides. There a couple additional functions like clocksource_unregister for removing 
given clock source from the clocksource_list and etc. But will not describe this functions 
in this part, because they are not important for us right now. Anyway if you are interesting in 
it, you can find it in the kernel/time/clocksource.c. 


That's all. 


Conclusion 


This is the end of the second part of the chapter that describes timers and timer 
management related stuff in the Linux kernel. In the previous part got acquainted with the 
following two concepts: jiffies and clocksource . In this part we saw some examples of 
the jiffies usage and knew more details about the clocksource concept. 


If you have questions or suggestions, feel free to ping me in twitter OxAX, drop me email or 
just create issue. 


Please note that English is not my first language and | am really sorry for any 
inconvenience. If you found any mistakes please send me PR to linux-insides. 
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Timers and time management in the Linux 
kernel. Part 3. 


The tick broadcast framework and dyntick 


This is third part of the chapter which describes timers and time management related stuff in 
the Linux kernel and we stopped on the clocksource framework in the previous part. We 
have started to consider this framework because it is closely related to the special counters 
which are provided by the Linux kernel. One of these counters which we already saw in the 
first part of this chapter is - jiffies . As | already wrote in the first part of this chapter, we 
will consider time management related stuff step by step during the Linux kernel 
initialization. Previous step was call of the: 


register_refined_jiffies(CLOCK_TICK_RATE); 


function which defined in the kernel/time/jiffies.c source code file and executes initialization 
of the refined_jiffies clock source for us. Recall that this function is called from the 

setup_arch function that defined in the 
https://github.com/torvalds/linux/blob/master/arch/x86/kernel/setup.c source code and 
executes architecture-specific (x86_64 in our case) initialization. Look on the implementation 
of the setup_arch and you will note that the call of the register_refined_jiffies is the last 
step before the setup_arch function will finish its work. 


There are many different xs6_64 specific things already configured after the end of the 

setup_arch execution. For example some early interrupt handlers already able to handle 
interrupts, memory space reserved for the initrd, DM! scanned, the Linux kernel log buffer is 
already set and this means that the printk function is able to work, e820 parsed and the 
Linux kernel already knows about available memory and and many many other architecture 
specific things (if you are interesting, you can read more about the setup_arch function and 
Linux kernel initialization process in the second chapter of this book). 


Now, the setup_arch finished its work and we can back to the generic Linux kernel code. 
Recall that the setup_arch function was called from the start_kernel function which is 
defined in the init/main.c source code file. So, we shall return to this function. You can see 
that there are many different function are called right after setup_arch function inside of the 

start_kernel function, but since our chapter is devoted to timers and time management 
related stuff, we will skip all code which is not related to this topic. The first function which is 
related to the time management in the Linux kernel is: 


tick_init(); 


inthe start_kernel . The tick_init function defined in the kernel/time/tick-common.c 


source code file and does two things: 


e Initialization of tick broadcast framework related data structures; 
e Initialization of full tickless mode related data structures. 


We didn't see anything related to the tick broadcast framework in this book and didn't 
know anything about tickless mode in the Linux kernel. So, the main point of this part is to 
look on these concepts and to know what are they. 


The idle process 


First of all, let's look on the implementation of the tick_init function. As | already wrote, 
this function defined in the kernel/time/tick-common.c source code file and consists from the 
two calls of following functions: 


void __init tick_init(void) 
{ 
tick_broadcast_init(); 
tick_nohz_init(); 


As you can understand from the paragraph's title, we are interesting only in the 
tick_broadcast_init function for now. This function defined in the kernel/time/tick- 
broadcast.c source code file and executes initialization of the tick broadcast framework 
related data structures. Before we will look on the implementation of the 
tick_broadcast_init function and will try to understand what does this function do, we need 
to know about tick broadcast framework. 


Main point of a central processor is to execute programs. But sometimes a processor may 
be in a special state when it is not being used by any program. This special state is called - 
idle. When the processor has no anything to execute, the Linux kernel launches idle task. 
We already saw a little about this in the last part of the Linux kernel initialization process. 
When the Linux kernel will finish all initialization processes in the start_kernel function 
from the init/main.c source code file, it will call the rest_init function from the same source 
code file. Main point of this function is to launch kernel init thread and the kthreadd 
thread, to call the schedule function to start task scheduling and to go to sleep by calling 
the cpu_idle_loop function that defined in the kerne!l/sched/idle.c source code file. 


The cpu_idle_loop function represents infinite loop which checks the need for rescheduling 

on each iteration. After the scheduler finds something to execute, the idle process will 

finish its work and the control will be moved to a new runnable task with the call of the 
schedule_preempt_disabled function: 


static void cp dle_loop( void) 
{ 
while (1) { 
while (!need_resched()) { 


cpuidle_idle_call(); 


schedule_preempt_disabled(); 


Of course, we will not consider full implementation of the cpu_idle_loop function and details 
of the idle state in this part, because it is not related to our topic. But there is one 
interesting moment for us. We know that the processor can execute only one task in one 
time. How does the Linux kernel decide to reschedule and stop idle process if the 
processor executes infinite loop in the cpu_idle_loop ? The answer is system timer 
interrupts. When an interrupt occurs, the processor stops the idle thread and transfers 
control to an interrupt handler. After the system timer interrupt handler will be handled, the 

need_resched will return true and the Linux kernel will stop idle process and will transfer 
control to the current runnable task. But handling of the system timer interrupts is not 
effective for power management, because if a processor is in idle state, there is little point 
in sending it a system timer interrupt. 


By default, there is the coNFIG_Hz_PERIODIC kernel configuration option which is enabled in 
the Linux kernel and tells to handle each interrupt of the system timer. To solve this problem, 
the Linux kernel provides two additional ways of managing scheduling-clock interrupts: 


The first is to omit scheduling-clock ticks on idle processors. To enable this behaviour in the 
Linux kernel, we need to enable the conF1G_No_Hz_IDLE kernel configuration option. This 
option allows Linux kernel to avoid sending timer interrupts to idle processors. In this case 
periodic timer interrupts will be replaced with on-demand interrupts. This mode is called - 

dyntick-idle mode. But if the kernel does not handle interrupts of a system timer, how can 
the kernel decide if the system has nothing to do? 


Whenever the idle task is selected to run, the periodic tick is disabled with the call of the 

tick_nohz_idle_enter function that defined in the kernel/time/tick-sched.c source code file 
and enabled with the call of the tick_nohz_idle_exit function. There is special concept in 
the Linux kernel which is called - clock event devices that are used to schedule the next 
interrupt. This concept provides API for devices which can deliver interrupts at a specific 
time in the future and represented by the clock_event_device structure in the Linux kernel. 
We will not dive into implementation of the clock_event_device structure now. We will see it 
in the next prat of this chapter. But there is one interesting moment for us right now. 


The second way is to omit scheduling-clock ticks on processors that are either in idle 
state or that have only one runnable task or in other words busy processor. We can enable 
this feature with the conF1IG_No_Hz_FULL kernel configuration option and it allows to reduce 
the number of timer interrupts significantly. 


Besides the cpu_idle_loop , idle processor can be in a sleeping state. The Linux kernel 
provides special cpuidle framework. Main point of this framework is to put an idle 
processor to sleeping states. The name of the set of these states is - c-states . But how 
does a processor will be woken if local timer is disabled? The linux kernel provides tick 
broadcast framework for this. The main point of this framework is assign a timer which is not 
affected by the c-states . This timer will wake a sleeping processor. 


Now, after some theory we can return to the implementation of our function. Let's recall that 
the tick_init function just calls two following functions: 


void __init tick it (void) 
{ 
tick_broadcast_init(); 
tick_nohz_init(); 


Let's consider the first function. The first tick_broadcast_init function defined in the 
kernel/time/tick-broadcast.c source code file and executes initialization of the tick 
broadcast framework related data structures. Let's look on the implementation of the 


tick_broadcast_init function: 


void _ init tick_broadcast_init(void) 

{ 
zalloc_cpumask_var(&tick_broadcast_mask, GFP_NOWAIT); 
zalloc_cpumask_var(&tick_broadcast_on, GFP_NOWAIT); 
zalloc_cpumask_var(&tmpmask, GFP_NOWAIT); 

#ifdef CONFIG_TICK_ONESHOT 
zalloc_cpumask_var(&tick_broadcast_oneshot_mask, GFP_NOWAIT); 
zalloc_cpumask_var(&tick_broadcast_pending_mask, GFP_NOWAIT); 
zalloc_cpumask_var(&tick_broadcast_force_mask, GFP_NOWAIT); 

#endif 


} 


As we can see, the tick_broadcast_init function allocates different coumasks with the help 
of the zalloc_cpumask_var function. The zalloc_cpumask_var function defined in the 
lib/cpumask.c source code file and expands to the call of the following function: 


bool zalloc_cpuma: ar(cpumask_var_t *mask, gfp_t flags) 
{ 

return alloc_cpumask_var(mask, flags | __GFP_ZERO); 
} 


Ultimately, the memory space will be allocated for the given cpumask with the certain flags 
with the help of the kmalloc_node function: 


*mask = kmalloc_node(cpumask_size(), flags, node); 


Now let's look on the cpumasks that will be initialized in the tick_broadcast_init function. 
As we can see, the tick_broadcast_init function will initialize six cpumasks , and moreover, 
initialization of the last three cpumasks will be depended on the coNFIG_TICK_ONESHOT kernel 


configuration option. 
The first three cpumasks are: 


e tick_broadcast_mask -the bitmap which represents list of processors that are in a 
sleeping mode; 

e tick_broadcast_on -the bitmap that stores numbers of processors which are in a 
periodic broadcast state; 

e tmpmask -this bitmap for temporary usage. 


As we already know, the next three cpumasks depends on the cONFIG_TICK_ONESHOT kernel 
configuration option. Actually each clock event devices can be in one of two modes: 


e periodic - clock events devices that support periodic events; 
e oneshot - clock events devices that capable of issuing events that happen only once. 


The linux kernel defines two mask for such clock events devices in the 
include/linux/clockchips.h header file: 


#define CLOCK_EVT_FEAT_PERIODIC 0x000001 
#define CLOCK_EVT_FEAT_ONESHOT 0x000002 


So, the last three cpumasks are: 


e tick_broadcast_oneshot_mask - Stores numbers of processors that must be notified; 
e tick_broadcast_pending_mask - Stores numbers of processors that pending broadcast; 
e tick_broadcast_force_mask - Stores numbers of processors with enforced broadcast. 


We have initialized six cpumasks inthe tick broadcast framework, and now we can 
proceed to implementation of this framework. 


The tick broadcast framework 


Hardware may provide some clock source devices. When a processor sleeps and its local 
timer stopped, there must be additional clock source device that will handle awakening of a 
processor. The Linux kernel uses these special clock source devices which can raise an 
interrupt at a specified time. We already know that such timers called clock events devices 
in the Linux kernel. Besides clock events devices. Actually, each processor in the system 
has its own local timer which is programmed to issue interrupt at the time of the next 
deferred task. Also these timers can be programmed to do a periodical job, like updating 

jiffies and etc. These timers represented by the tick_device structure in the Linux 
kernel. This structure defined in the kernel/time/tick-sched.h header file and looks: 


struct tick_device { 
struct clock_event_device *evtdev; 
enum tick_device_mode mode; 


Note, that the tick_device structure contains two fields. The first field - evtdev represents 
pointer to the clock_event_device structure that defined in the include/linux/clockchips.h 
header file and represents descriptor of a clock event device. A clock event device allows 
to register an event that will happen in the future. As | already wrote, we will not consider 
clock_event_device structure and related API in this part, but will see it in the next part. 


The second field of the tick_device structure represents mode of the tick_device . AS we 
already know, the mode can be one of the: 


num tick_device_mode { 
TICKDEV_MODE_PERIODIC, 
TICKDEV_MODE_ONESHOT, 


}; 


Each clock events device in the system registers itself by the call of the 

clockevents_register_device function Or clockevents config and_register function during 
initialization process of the Linux kernel. During the registration of a new clock events 
device, the Linux kernel calls the tick_check_new_device function that defined in the 
kernel/time/tick-common.c source code file and checks the given clock events device 
should be used by the Linux kernel. After all checks, the tick_check_new_device function 
executes a call of the: 


tick_install_broadcast_device(newdev) ; 


function that checks that the given clock event device can be broadcast device and install 
it, if the given device can be broadcast device. Let's look on the implementation of the 


tick_install_broadcast_device function: 


void tick_install_broadcast_device(struct clock_event_device *dev) 
{ 


struct clock_event_device *cur = tick_broadcast_device.evtdev; 


if (!tick_check_broadcast_device(cur, dev)) 
return; 


if (!try_module_get(dev->owner ) ) 
return; 


clockevents_exchange_device(cur, dev); 


if (cur) 
cur->event_handler = clockevents_handle_noop; 


tick_broadcast_device.evtdev = dev; 


if (!cpumask_empty(tick_broadcast_mask) ) 
tick_broadcast_start_periodic(dev); 


if (dev->features & CLOCK_EVT_FEAT_ONESHOT ) 
tick_clock_notify(); 


First of all we get the current clock event device from the tick_broadcast_device . The 
tick_broadcast_device defined in the kernel/time/tick-common.c source code file: 


static struct tick_device tick_broadcast_device; 


and represents external clock device that keeps track of events for a processor. The first 
step after we got the current clock device is the call of the tick_check_broadcast_device 
function which checks that a given clock events device can be utilized as broadcast device. 
The main point of the tick _check_broadcast_device function is to check value of the 
features field of the given clock events device. As we can understand from the name of 
this field, the features field contains a clock event device features. Available values 
defined in the include/linux/clockchips.h header file and can be one of the 
CLOCK_EVT_FEAT_PERIODIC - which represents a clock events device which supports periodic 
events and etc. So, the tick_check_broadcast_device function check features flags for 
CLOCK_EVT_FEAT_ONESHOT , CLOCK_EVT_FEAT_DumMMy and other flags and returns false ifthe 
given clock events device has one of these features. In other way the 
tick_check_broadcast_device function compares ratings of the given clock event device 
and current clock event device and returns the best. 


After the tick_check_broadcast_device function, we can see the call of the try_module_get 
function that checks module owner of the clock events. We need to do it to be sure that the 
given clock events device was correctly initialized. The next step is the call of the 

clockevents_exchange_device function that defined in the kernel/time/clockevents.c source 
code file and will release old clock events device and replace the previous functional handler 
with a dummy handler. 


In the last step of the tick_install_broadcast_device function we check that the 
tick_broadcast_mask is not empty and start the given clock events device in periodic mode 
with the call of the tick_broadcast_start_periodic function: 


if (!cpumask_empty(tick_broadcast_mask) ) 
tick_broadcast_start_periodic(dev); 


if (dev->features & CLOCK_EVT_FEAT_ONESHOT ) 
tick_clock_notify(); 


The tick_broadcast_mask filled in the tick _device_uses_broadcast function that checks a 
clock events device during registration of this clock events device: 


int cpu = smp_processor_id(); 


int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu) 
{ 
if (!tick_device_is_functional(dev)) { 
cpumask_set_cpu(cpu, tick_broadcast_mask); 
} 
} 


More about the smp_processor_id Macro you can read in the fourth part of the Linux kernel 


initialization process chapter. 


The tick_broadcast_start_periodic function check the given clock event device and call 


the tick_setup_periodic function: 


static void tick_broadcast_start_periodic(struct clock_event_device *bc) 


{ 
if (bc) 
tick_setup_periodic(bc, 1); 


that defined in the kernel/time/tick-common.c source code file and sets broadcast handler for 
the given clock event device by the call of the following function: 


tick_set_periodic_handler(dev, broadcast); 


This function checks the second parameter which represents broadcast state ( on or off ) 
and sets the broadcast handler depends on its value: 


void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast) 


{ 
if (!broadcast) 
dev->event_handler = tick_handle_periodic; 


else 
dev->event_handler = tick_handle_periodic_broadcast; 


When an clock event device will issue an interrupt, the dev->event_handler will be called. 
For example, let's look on the interrupt handler of the high precision event timer which is 
located in the arch/x86/kernel/hpet.c source code file: 


static irgreturn_t hpet_interrupt_handler(int irg, void *data) 
{ 

struct hpet_dev *dev = (struct hpet_dev *)data; 

struct clock_event_device *hevt = &dev->evt; 


if (!hevt->event_handler) { 
printk(KERN_INFO "Spurious HPET timer interrupt on HPET timer %d\n", 
dev->num); 
return IRQ_HANDLED; 


hevt->event_handler(hevt); 
return IRQ_HANDLED; 


The hpet_interrupt_handler gets the irq specific data and check the event handler of the 

clock event device. Recall that we just set in the tick_set_periodic_handler function. So 
the tick_handler_periodic_broadcast function will be called in the end of the high precision 
event timer interrupt handler. 


The tick_handler_periodic_broadcast function calls the 


bc_local = tick_do_periodic_broadcast(); 


function which stores numbers of processors which have asked to be woken up in the 
temporary cpumask and call the tick_do_broadcast function: 


cpumask_and(tmpmask, cpu_online_mask, tick_broadcast_mask); 
return tick_do_broadcast(tmpmask) ; 


The tick_do_broadcast calls the broadcast function of the given clock events which sends 
IPI interrupt to the set of the processors. In the end we can call the event handler of the 
given tick_device : 


if (bc_local) 
td->evtdev->event_handler(td->evtdev) ; 


which actually represents interrupt handler of the local timer of a processor. After this a 
processor will wake up. That is all about tick broadcast framework in the Linux kernel. We 
have missed some aspects of this framework, for example reprogramming of a clock event 


device and broadcast with the oneshot timer and etc. But the Linux kernel is very big, it is 
not real to cover all aspects of it. | think it will be interesting to dive into with yourself. 


If you remember, we have started this part with the call of the tick_init function. We just 
consider the tick_broadcast_init function and releated theory, but the tick_init function 
contains another call of a function and this function is - tick_nohz_init . Let's look on the 
implementation of this function. 


Initialization of dyntick related data structures 


We already saw some information about dyntick concept in this part and we know that this 
concept allows kernel to disable system timer interrupts in the idle state. The 

tick_nohz_init function makes initialization of the different data structures which are 
related to this concept. This function defined in the kernel/time/tick-sched.c source code file 
and starts from the check of the value of the tick_nohz_full_running variable which 
represents state of the tick-less mode for the idle state and the state when system timer 
interrups are disabled during a processor has only one runnable task: 


if (!tick_nohz_full_running) { 
if (tick_nohz_init_all() < 0) 
return; 


If this mode is not running we call the tick_nohz_init_all function that defined in the same 
source code file and check its result. The tick_nohz_init_all function tries to allocate the 
tick_nohz_full_mask with the call of the alloc_cpumask_var that will allocate space for a 
tick_nohz_full_mask . The tck_nohz_full_mask will store numbers of processors that have 
enabled full No_Hz . After successful allocation of the tick_nohz_full_mask we set all bits in 
the tick_nogz_full_mask , set the tick_nohz_full_running and return result to the 


tick_nohz_init function: 


static int tick_nohz_init_all(void) 
{ 
amie rig s oils 
#ifdef CONFIG_NO_HZ_FULL_ALL 
if (!alloc_cpumask_var(&tick_nohz_full_mask, GFP_KERNEL)) { 
WARN(1, "NO_HZ: Can't allocate full dynticks cpumask\n"); 
return err; 


} 

err = 0; 

cpumask_setall(tick_nohz_full_mask); 

tick_nohz_full_running = true; 
#endif 

return err; 


In the next step we try to allocate a memory space for the housekeeping_mask : 


if (!alloc_cpumask_var(&housekeeping_mask, GFP_KERNEL)) { 
WARN(1, "NO_HZ: Can't allocate not-full dynticks cpumask\n"); 
cpumask_clear(tick_nohz_full_mask); 
tick_nohz_full_running = false; 
return; 


This cpumask will store number of processor for housekeeping or in other words we need at 
least in one processor that will not be in No_Hz mode, because it will do timekeeping and 
etc. After this we check the result of the architecture-specific arch_irq_work_has_interrupt 
function. This function checks ability to send inter-processor interrupt for the certain 
architecture. We need to check this, because system timer of a processor will be disabled 
during No_Hz mode, so there must be at least one online processor which can send inter- 
processor interrupt to awake offline processor. This function defined in the 
arch/x86/include/asm/irq_work.h header file for the x86_64 and just checks that a processor 
has APIC from the CPUID: 





static inline bool arch_irgq_work_has_interrupt(void) 


return cpu_has_apic; 


If a processor has not APIc , the Linux kernel prints warning message, clears the 
tick_nohz_full_mask Cpumask, copies numbers of all possible processors in the system to 
the housekeeping_mask and resets the value of the tick_nohz_full_running variable: 


if (!arch_irq work_has_interrupt()) { 





pr_warning("NO_HZ: Can't run full dynticks because arch doesn't " 
"support irq work self-IPIs\n"); 

cpumask_clear(tick_nohz_full_mask); 

cpumask_copy(housekeeping_mask, cpu_possible_mask); 

tick_nohz_full_running = false; 

return, 


After this step, we get the number of the current processor by the call of the 
smp_processor_id and check this processor in the tick_nohz_full_mask . If the 
tick_nohz_full_mask contains a given processor we clear appropriate bit in the 


tick_nohz_full_mask : 


cpu = smp_processor_id(); 


if (cpumask_test_cpu(cpu, tick_nohz_full_mask)) { 
pr_warning("NO_HZ: Clearing %d from nohz_full range for timekeeping\n", cpu); 
cpumask_clear_cpu(cpu, tick_nohz_full_mask); 


Because this processor will be used for timekeeping. After this step we put all numbers of 
processors that are in the cpu_possible_ mask and notin the tick_nohz_full_mask : 


cpumask_andnot(housekeeping_mask, 
cpu_possible_ mask, tick_nohz_full_mask); 


After this operation, the housekeeping_mask will contain all processors of the system except 
a processor for timekeeping. In the last step of the tick_nohz_init_all function, we are 
going through all processors that are defined in the tick_nohz_full_mask and call the 
following function for an each processor: 


for_each_cpu(cpu, tick_nohz_full_mask) 
context_tracking_cpu_set(cpu); 


The context_tracking_cpu_set function defined in the kernel/context_tracking.c source code 

file and main point of this function is to set the context_tracking.active percpu variable to 
true . When the active field will be set to true for the certain processor, all context 

switches will be ignored by the Linux kernel context tracking subsystem for this processor. 


That's all. This is the end of the tick_nohz_init function. After this No_Hz related data 
structures will be initialzed. We didn't see API of the No_Hz mode, but will see it soon. 


Conclusion 


This is the end of the third part of the chapter that describes timers and timer management 
related stuff in the Linux kernel. In the previous part got acquainted with the clocksource 
concept in the Linux kernel which represents framework for managing different clock source 
in a interrupt and hardware characteristics independent way. We continued to look on the 
Linux kernel initialization process in a time management context in this part and got 
acquainted with two new concepts for us: the tick broadcast framework and tick-less 
mode. The first concept helps the Linux kernel to deal with processors which are in deep 
sleep and the second concept represents the mode in which kernel may work to improve 
power management of idle processors. 


In the next part we will continue to dive into timer management related things in the Linux 
kernel and will see new concept for us - timers . 


If you have questions or suggestions, feel free to ping me in twitter OxAX, drop me email or 
just create issue. 


Please note that English is not my first language and I am really sorry for any 
inconvenience. If you found any mistakes please send me PR to linux-insides. 
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Timers and time management in the Linux 
kernel. Part 4. 


Timers 


This is fourth part of the chapter which describes timers and time management related stuff 
in the Linux kernel and in the previous part we knew about the tick broadcast framework 
and No_Hz mode in the Linux kernel. We will continue to dive into the time management 
related stuff in the Linux kernel in this part and will be acquainted with yet another concept in 
the Linux kernel- timers . Before we will look at timers in the Linux kernel, we have to learn 
some theory about this concept. Note that we will consider software timers in this part. 


The Linux kernel provides a software timer concept to allow to kernel functions could be 
invoked at future moment. Timers are widely used in the Linux kernel. For example, look in 
the net/netfilter/ipset/ip_set_list_set.c source code file. This source code file provides 
implementation of the framework for the managing of groups of IP addresses. 


We can find the list_set structure that contains gc filed in this source code file: 


struct list_set { 


struct timer_list gc; 


Not that the gc filed has timer_list type. This structure defined in the 
include/linux/timer.h header file and main point of this structure is to store dynamic timers in 
the Linux kernel. Actually, the Linux kernel provides two types of timers called dynamic 
timers and interval timers. First type of timers is used by the kernel, and the second can be 
used by user mode. The timer_list structure contains actual dynamic timers. The 

list_set contains gc timer in our example represents timer for garbage collection. This 
timer will be initialized in the list_set_gc_init function: 


static void 
list_set_gc_init(struct ip_set *set, void (*gc)(unsigned long ul set)) 


{ 


struct list_set *map = set->data; 


map->gc.function = gc; 
map->gc.expires = jiffies + IPSET_GC_PERIOD(set->timeout) * HZ; 


A function that is pointed by the gc pointer, will be called after timeout which is equal to the 


map->gc.expires 


Ok, we will not dive into this example with the netfilter, because this chapter is not about 
network related stuff. But we saw that timers are widely used in the Linux kernel and learned 
that they represent concept which allows to functions to be called in future. 


Now let's continue to research source code of Linux kernel which is related to the timers and 
time management stuff as we did it in all previous chapters. 


Introduction to dynamic timers in the Linux 
kernel 


As | already wrote, we knew about the tick broadcast framework and No_Hz mode in the 
previous part. They will be initialized in the init/main.c source code file by the call of the 

tick_init function. If we will look at this source code file, we will see that the next time 
management related function is: 


init_timers(); 


This function defined in the kerne!l/time/timer.c source code file and contains calls of four 
functions: 


void __init ini 


{ 


t 


timers(void) 


init_timer_cpus(); 


init_timer_stats(); 


timer_register_cpu_notifier(); 
open_softirq(TIMER_SOFTIRQ, run_timer_softirq); 


Let's look on implementation of each function. The first function iS init_timer_cpus defined 


in the same source code file and just calls the init_timer_cpu function for each possible 


processor in the system: 


static void _ init init_timer_cpus(void) 


{ 


int cpu; 


for_each_possible_cpu(cpu) 


init_timer_cpu(cpu); 


If you do not know or do not remember what is ita possible cpu, you can read the special 


part of this book which describes cpumask concept in the Linux kernel. In short words, a 


possible processor is a processor which can be plugged in anytime during the life of the 


system. 


The init_timer_cpu function does main work for us, namely it executes initialization of the 


tvec_base structure for each processor. This structure defined in the kernel/time/timer.c 


source code file and stores data related to a dynamic timer for a certain processor. Let's 


look on the definition of this structure: 


struct tvec_base { 


spinlock_t lock; 


struct timer_list *running_timer; 


unsigned long timer_jiffies; 


unsigned long next_timer; 


unsigned long active_timers; 


unsigned long all_timers; 


int cpu; 


bool migration_enabled; 


bool nohz_active; 


struct 
struct 
struct 
struct 
struct 


} cacheline_| 


tvec_root tv1; 


tvec 
tvec 
tvec 
tvec 


tv2; 
tv3; 
tv4; 
tv5; 
aligned; 


The thec_base structure contains following fields: The lock for tvec_base protection, the 
next running_timer field points to the currently running timer for the certain processor, the 

timer_jiffies fields represents the earliest expiration time (it will be used by the Linux 
kernel to find already expired timers). The next field - next_timer contains the next pending 
timer for a next timer interrupt in a case when a processor goes to sleep and the No_Hz 
mode is enabled in the Linux kernel. The active_timers field provides accounting of non- 
deferrable timers or in other words all timers that will not be stopped during a processor will 
go to sleep. The all_timers field tracks total number of timers or active timers + 
deferrable timers. The cpu field represents number of a processor which owns timers. The 

migration_enabled and nohz_active fields are represent opportunity of timers migration to 
another processor and status of the No_Hz mode respectively. 


The last five fields of the tvec_base structure represent lists of dynamic timers. The first 
tv1 field has: 


#define TVR_SIZE (1 << TVR_BITS) 
#define TVR_BITS (CONFIG_BASE_SMALL ? 6 : 8) 


struct tvec_root { 
struct hlist_head vec[TVR_SIZE]; 
J; 


type. Note that the value of the TVR_SIzE depends on the coNFIG_BASE_SMALL kernel 
configuration option: 


Terminal 


File Edit View Search Terminal Help 


Configure standard kernel features (expert users) 
Arrow keys navigate the menu. <Enter> selects submenus ---> (or empty 
submenus ----). Highlighted letters are hotkeys. Pressing <Y> 
includes, <N> excludes, <M> modularizes features. Press <Esc><Esc> to 
exit, <?> for Help, </> for Search. Legend: [*] built-in [ ] 


Enable support for printk 
BUG() support 
Enable ELF core dumps 
Enable PC-Speaker support 
full-sized data structures for core 
Enable futex support 
Enable eventpoll support 
Enable signalfd() system call 


< Exit > < Help > < Save > < Load > 





that reduces size of the kernel data structures if disabled. The v1 is array that may contain 
64 or 256 elements where an each element represents a dynamic timer that will decay 
within the next 255 system timer interrupts. Next three fields: tv2 , tv3 and tv4 are lists 
with dynamic timers too, but they store dynamic timers which will decay the next 2.14 - 1, 
2020 - 1 and 2426 respectively. The last tvs field represents list which stores dynamic 
timers with a large expiring period. 


So, now we saw the tvec_base structure and description of its fields and we can look on the 
implementation of the init_timer_cpu function. As | already wrote, this function defined in 
the kernel/time/timer.c source code file and executes initialization of the tvec_bases : 


static void __init init_timer_cpu(int cpu) 


{ 
struct tvec_base *base = per_cpu_ptr(&tvec_bases, cpu); 
base->cpu = cpu; 
spin_lock_init(&base->lock) ; 
base->timer_jiffies = jiffies; 
base->next_timer = base->timer_jiffies; 
} 


The tvec_bases represents per-cpu variable which represents main data structure for a 
dynamic timer for a given processor. This per-cpu variable defined in the same source 
code file: 


static DEFINE_PER_CPU(struct tvec_base, tvec_bases); 


First of all we're getting the address of the tvec_bases for the given processor to base 
variable and as we got it, we are starting to initialize some of the tvec_base fields in the 

init_timer_cpu function. After initialization of the per-cpu dynamic timers with the jiffies 
and the number of a possible processor, we need to initialize a tstats_lookup_lock Spinlock 
inthe init_timer_stats function: 


void __init init_timer_stats(void) 
{ 


int cpu; 


for_each_possible_cpu(cpu) 
raw_spin_lock_init(&per_cpu(tstats_lookup_lock, cpu)); 


The tstats_lookcup_lock variable represents per-cpu raw spinlock: 


static DEFINE_PER_CPU(raw_spinlock_t, tstats_lookup_lock); 


which will be used for protection of operation with statistics of timers that can be accessed 
through the procfs: 


static int init init_tstats_procfs(void) 


{ 
struct proc_dir_entry *pe; 
pe = proc_create("timer_stats", 0644, NULL, &tstats_fops); 
if (!pe) 
return -ENOMEM; 
return 0; 
} 


For example: 


$ cat /proc/timer_stats 
Timerstats sample period: 3.888770 s 


12, © swapper hrtimer_stop_sched_tick (hrtimer_sched_tick) 
15, 1 swapper hcd_submit_urb (rh_timer_func) 

4, 959 kedac schedule_timeout (process_timeout) 

aby. 9 swapper page_writeback_init (wb_timer_fn) 

28, 9 swapper hrtimer_stop_sched_tick (hrtimer_sched_tick) 
22, 2948 IRQ 4 tty_flip_buffer_push (delayed_work_timer_fn) 


The next step after initialization of the tstats_lookup_lock spinlock is the call of the 
timer_register_cpu_notifier function. This function depends on the coNFIG HOTPLUG_ CPU 
kernel configuration option which enables support for hotplug processors in the Linux kernel. 


When a processor will be logically offlined, a notification will be sent to the Linux kernel with 
the cPU_DEAD orthe cpu_DEAD_FROZEN event by the call of the cpu_notifier macro: 


#ifdef CONFIG_HOTPLUG_CPU 


static inline void timer_register_cpu_notifier(void) 
{ 


cpu_notifier(timer_cpu_notify, ©); 
#else 
static inline void timer_register_cpu_notifier(void) { } 
#endif /* CONFIG_HO 


In this case the timer_cpu_notify will be called which checks an event type and will call the 
migrate_timers function: 


static int timer_cpu_notify(struct notifier_block *self, 
unsigned long action, void *hcpu) 


switch (action) { 

case CPU_DEAD: 

case CPU_DEAD_FROZEN: 
migrate_timers((long)hcpu); 
break; 

default: 
break; 


return NOTIFY_OK; 


This chapter will not describe hotplug related events in the Linux kernel source code, but if 
you are interesting in such things, you can find implementation of the migrate_timers 
function in the kernel/time/timer.c source code file. 


The last step in the init_timers function is the call of the: 


open_softirgq(TIMER_SOFTIRQ, run_timer_softirgq); 


function. The open_softirq function may be already familar to you if you have read the 
ninth part about the interrupts and interrupt handling in the Linux kernel. In short words, the 

open_softirq function defined in the kernel/softirg.c source code file and executes 
initialization of the deferred interrupt handler. 


In our case the deferred function is the run_timer_softirgq function that is will be called after 
a hardware interrupt in the do_IRQ function which defined in the arch/x86/kernel/irg.c 
source code file. The main point of this function is to handle a software dynamic timer. The 
Linux kernel does not do this thing during the hardware timer interrupt handling because this 
is time consuming operation. 


Let's look on the implementation of the run_timer_softirgq function: 


static void run_timer_softirq(struct softirq_action *h) 
{ 


struct tvec_base *base = this_cpu_ptr(&tvec_bases); 


if (time_after_eq(jiffies, base->timer_jiffies) ) 
__run_timers(base); 


At the beginning of the run_timer_softirq function we geta dynamic timer for a current 
processor and compares the current value of the jiffies with the value of the timer_jiffies 
for the current structure by the call of the time_after_eq macro which is defined in the 
include/linux/jiffies.n header file: 


#define time_after_eq(a,b) N 
(typecheck(unsigned long, a) && \ 
typecheck(unsigned long, b) && \ 
((long)((a) - (b)) >= 9)) 


Reclaim that the timer_jiffies field of the tvec_base structure represents the relative time 
when functions delayed by the given timer will be executed. So we compare these two 
values and if the current time represented by the jiffies is greater than base- 
>timer_jiffies , we call the __run_timers function that defined in the same source code file. 
Let's look on the implementation of this function. 


As | just wrote, the _run_timers function runs all expired timers for a given processor. This 
function starts from the acquiring of the tvec_base's lock to protect the tvec_base structure 


static inline void __run_timers(struct tvec_base *base) 


{ 
struct timer_list *timer; 
spin_lock_irq(&base->lock); 
spin_unlock_irgq(&base->lock) ; 
} 


After this it starts the loop while the timer_jiffies will not be greater than the jiffies : 


while (time_after_eq(jiffies, base->timer_jiffies)) { 


We can find many different manipulations in the our loop, but the main point is to find 
expired timers and call delayed functions. First of all we need to calculate the index of the 
base->tv1 list that stores the next timer to be handled with the following expression: 


index = base->timer_jiffies & TVR_MASK; 


where the TVR_MASK is a mask forthe getting of the tvec_root->vec elements. As we got 
the index with the next timer which must be handled we check its value. If the index is zero， 
we go through all lists in our cascade table tv2, tv3 and etc., and rehashing it with the 
call of the cascade function: 


if (!index && 
(!cascade(base, &base->tv2, INDEX(0))) && 
(!cascade(base, &base->tv3, INDEX(1))) && 
!cascade(base, &base->tv4, INDEX(2))) 
cascade(base, &base->tv5, INDEX(3)); 


After this we increase the value of the base->timer_jiffies : 


++base->timer_jiffies; 


In the last step we are executing a corresponding function for each timer from the list in a 
following loop: 


hlist_move_list(base->tv1.vec + index, head); 


while (!hlist_empty(head)) { 


timer = hlist_entry(head->first, struct timer_list, entry); 
fn = timer->function; 
data = timer->data; 


spin_unlock(&base->lock); 


call_timer_fn(timer, fn, data); 
spin_lock(&base->lock); 


where the call_timer_fn just call the given function: 


static void call_timer_fn(struct timer_list *timer, void (*fn)(unsigned long), 
unsigned long data) 


fn(data); 


That's all. The Linux kernel has infrastructure for dynamic timers from this moment. We will 
not dive into this interesting theme. As | already wrote the timers is a widely used concept 
in the Linux kernel and nor one part, nor two parts will not cover understanding of such 
things how it implemented and how it works. But now we know about this concept, why does 
the Linux kernel needs in it and some data structures around it. 


Now let's look usage of dynamic timers in the Linux kernel. 


Usage of dynamic timers 


As you already can noted, if the Linux kernel provides a concept, it also provides API for 
managing of this concept and the dynamic timers concept is not exception here. To use a 
timer in the Linux kernel code, we must define a variable with a timer_list type. We can 
initialize our timer_list structure in two ways. The first is to use the init_timer macro 
that defined in the include/linux/timer.h header file: 


#define init_timer(timer) \ 
__init_timer((timer), 0) 


#define init_timer(_timer, _flags) \ 
init_timer_key((_timer), (_flags), NULL, NULL) 





where the init_timer_key function just calls the: 


do_init_timer(timer, flags, name, key); 


function which fields the given timer with default values. The second way is to use the: 


#define TIMER_INITIALIZER(_function, _expires, _data) \ 
__TIMER_INITIALIZER((_function), (_expires), (_data), 0) 


macro which will initilize the given timer_list structure too. 


After a dynamic timer is initialzed we can start this timer with the call of the: 


void add_timer(struct timer_list * timer); 


function and stop it with the: 


int del_timer(struct timer_list * timer); 
function. 
That's all. 
Conclusion 


This is the end of the fourth part of the chapter that describes timers and timer management 
related stuff in the Linux kernel. In the previous part we got acquainted with the two new 
concepts: the tick broadcast framework and the No_Hz mode. In this part we continued to 
dive into time managemented related stuff and got acquainted with the new concept - 

dynamic timer or software timer. We didn't saw implementation of a dynamic timers 
management code in details in this part but saw data structures and API around this 
concept. 


In the next part we will continue to dive into timer management related things in the Linux 
kernel and will see new concept for us - timers . 


If you have questions or suggestions, feel free to ping me in twitter OxAX, drop me email or 
just create issue. 


Please note that English is not my first language and I am really sorry for any 
inconvenience. If you found any mistakes please send me PR to linux-insides. 


Links 


e |P 

e netfilter 
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e cpumask 
e interrupt 
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Timers and time management in the Linux 
kernel. Part 5. 


Introduction to the clockevents framework 


This is fifth part of the chapter which describes timers and time management related stuff in 
the Linux kernel. As you might noted from the title of this part, the clockevents framework 
will be discussed. We already saw one framework in the second part of this chapter. It was 

clocksource framework. Both of these frameworks represent timekeeping abstractions in 
the Linux kernel. 


At first let's refresh your memory and try to remember what is it clocksource framework and 
and what its purpose. The main goal of the clocksource framework is to provide timeline . 
As described in the documentation: 


For example issuing the command 'date' on a Linux system will eventually read the 
clock source to determine exactly what time it is. 


The Linux kernel supports many different clock sources. You can find some of them in the 
drivers/closksource. For example old good Intel 8253 - programmable interval timer with 
1193182 Hz frequency, yet another one - ACP! PM timer with 3579545 Hz frequency. 
Besides the drivers/closksource directory, each architecture may provide own architecture- 
specific clock sources. For example x86 architecture provides High Precision Event Timer, 
or for example powerpc provides access to the processor timer through timebase register. 


Each clock source provides monotonic atomic counter. As | already wrote, the Linux kernel 
supports a huge set of different clock source and each clock source has own parameters like 
frequency. The main goal of the clocksource framework is to provide AP! to select best 
available clock source in the system i.e. a clock source with the highest frequency. 
Additional goal of the clocksource framework is to represent an atomic counter provided by 
a clock source in human units. In this time, nanoseconds are the favorite choice for the time 
value units of the given clock source in the Linux kernel. 


The clocksource framework represented by the clocksource structure which is defined in 
the include/linux/clocksource.h header code file which contains name of a clock source, 
rating of certain clock source in the system (a clock source with the higher frequency has the 
biggest rating in the system), list of all registered clock source in the system, enable 

and disable fields to enable and disable a clock source, pointer to the read function 
which must return an atomic counter of a clock source and etc. 


Additionally the clocksource structure provides two fields: mult and shift which are 
needed for translation of an atomic counter which is provided by a certain clock source to 
the human units, i.e. nanoseconds. Translation occurs via following formula: 


ns ~= (clocksource * mult) >> shift 


As we already know, besides the clocksource structure, the clocksource framework 
provides an API for registration of clock source with different frequency scale factor: 








static inline int clocksource_register_hz(struct clocksource *cs, u32 hz) 

static inline int clocksource_register_khz(struct clocksource *cs, u32 khz) 
A clock source unregistration: 

int clocksource_unregister(struct clocksource *cs) 


and etc. 


Additionally to the clocksource framework, the Linux kernel provides clockevents 
framework. As described in the documentation: 


Clock events are the conceptual reverse of clock sources 


Main goal of the is to manage clock event devices or in other words - to manage devices 
that allow to register an event or in other words interrupt that is going to happen at a defined 
point of time in the future. 


Now we know a little about the clockevents framework in the Linux kernel, and now time is 
to see on it API. 


API of clockevents framework 


The main structure which described a clock event device is clock_event_device structure. 
This structure is defined in the include/linux/clockchips.h header file and contains a huge set 
of fields. as well as the clocksource structure ithas name fields which contains human 
readable name of a clock event device, for example local APIC timer: 


static struct clock_event_device lapic_clockevent = { 
.name = "lapic", 


Addresses of the event_handler , set_next_event , next_event functions for a certain clock 
event device which are an interrupt handler, setter of next event and local storage for next 
event respectively. Yet another field of the clock_event_device structure is - features field. 
Its value maybe on of the following generic features: 


#define CLOCK_EVT_FEAT_PERIODIC 0x000001 
#define CLOCK_EVT_FEAT_ONESHOT 0x000002 


Where the cLOocK_EVT_FEAT_PERIODIC represents device which may be programmed to 
generate events periodically. The cLock_EVT_FEAT_ONESHOT represents device which may 
generate an event only once. Besides these two features, there are also architecture- 
specific features. For example x86_64 supports two additional features: 


#define CLOCK_EVT_FEAT_C3STOP 0x000008 


The first cLock_EvT_FEAT_c3stop means that a clock event device will be stopped in the C3 
state. Additionally the clock_event_device structure has mult and shift fields as well as 

clocksource structure. The clocksource structure also contains other fields, but we will 
consider it later. 


After we considered part of the clock_event_device structure, time is to look atthe API of 
the clockevents framework. To work with a clock event device, first of all we need to 
initialize clock_event_device structure and register a clock events device. The clockevents 
framework provides following API for registration of clock event devices: 


void clockevents_register_device(struct clock_event_device *dev) 


{ 


This function defined in the kernel/time/clockevents.c source code file and as we may see, 
the clockevents_register_device function takes only one parameter: 


e address of a clock_event_device structure which represents a clock event device. 


So, to register a clock event device, at first we need to initialize clock_event_device 
structure with parameters of a certain clock event device. Let's take a look at one random 
clock event device in the Linux kernel source code. We can find one in the 
drivers/closksource directory or try to take a look at an architecture-specific clock event 
device. Let's take for example - Periodic Interval Timer (PIT) for at91sam926x. You can find 
its implementation in the drivers/closksource. 


First of all let's look at initialization of the clock_event_device structure. This occurs in the 


at91sam926x_pit_common_init function: 


struct pit_data { 


struct clock_event_device clkevt; 
J; 
static void _ init at91sam926x_pit_common_init(struct pit_data *data) 
{ 
data->clkevt.name = "pit"; 
data->clkevt.features = CLOCK_EVT_FEAT_PERIODIC; 
data->clkevt.shift = 32; 
data->clkevt.mult = div_sc(pit_rate, NSEC_PER_SEC, data->clkevt.shift); 
data->clkevt.rating = 100; 
data->clkevt.cpumask = cpumask_of (0); 
data->clkevt.set_state_shutdown = pit_clkevt_shutdown; 
data->clkevt.set_state_periodic = pit_clkevt_set_periodic; 
data->clkevt.resume = at91sam926x_pit_resume; 
data->clkevt.suspend = at91sam926x_pit_suspend; 
} 


Here we can see that at91sam926x_pit_common_init takes one parameter - pointer to the 
pit_data structure which contains clock_event_device structure which will contain clock 
event related information of the at91sam926x periodic Interval Timer. At the start we fill 
name of the timer device and its features . In our case we deal with periodic timer which as 
we already know may be programmed to generate events periodically. 


The next two fields shift and mult are familiar to us. They will be used to translate 
counter of our timer to nanoseconds. After this we set rating of the timer to 100 . This 
means if there will not be timers with higher rating in the system, this timer will be used for 


timekeeping. The next field - cpumask indicates for which processors in the system the 
device will work. In our case, the device will work for the first processor. The cpumask_of 
macro defined in the include/linux/cpumask.h header file and just expands to the call of the: 


#define cpumask_of(cpu) (get_cpu_mask(cpu) ) 


Where the get_cpu_mask returns the coumask containing just a given cpu number. More 
about cpumasks concept you may read in the CPU masks in the Linux kernel part. In the last 
four lines of code we set callbacks for the clock event device suspend/resume, device 
shutdown and update of the clock event device state. 


After we finished with the initialization of the ato1sam926x periodic timer, we can register it 
by the call of the following functions: 


clockevents_register_device(&data->clkevt); 


Now we can consider implementation of the clockevent_register_device function. As | 
already wrote above, this function is defined in the kernel/time/clockevents.c source code file 
and starts from the initialization of the initial event device state: 


clockevent_set_state(dev, CLOCK_EVT_STATE_DETACHED) ; 


Actually, an event device may be in one of this states: 


enum clock_event_state { 
CLOCK_EVT_STATE_DETACHED, 
CLOCK_EVT_STATE_SHUTDOWN, 
CLOCK_EVT_STATE_PERIODIC, 
CLOCK_EVT_STATE_ONESHOT, 
CLOCK_EVT_STATE_ONESHOT_STOPPED, 


}; 


Where: 


© CLOCK_EVT_STATE_DETACHED - a clock event device is not not used by clockevents 
framework. Actually it is initial state of all clock event devices; 

e CLOCK_EVT_STATE_SHUTDOWN -a clock event device is powered-off; 

e CLOCK_EVT_STATE_PERTODIC -a clock event device may be programmed to generate 
event periodically; 

e CLOCK_EVT_STATE_ONESHOT - a clock event device may be programmed to generate event 
only once; 

e CLOCK_EVT_STATE_ONESHOT_STOPPED - a Clock event device was programmed to generate 


event only once and now it is temporary stopped. 


The implementation of the clock_event_set_state function is pretty easy: 


static inline void clockevent_set_state(struct clock_event_device *dev, 
enum clock_event_state state) 
{ 
dev->state use accessors = state; 
} 


As we can see, it just fills the state use accessors field of the given clock_event_device 
structure with the given value which is in our case is CLOCK_EVT_STATE_DETACHED . Actually all 
clock event devices has this initial state during registration. The state_use_accessors field of 
the clock_event_device structure provides current state of the clock event device. 


After we have set initial state of the given clock_event_device structure we check that the 
cpumask of the given clock event device is not zero: 


if (!dev->cpumask) { 
WARN_ON(num_possible_cpus() > 1); 
dev->cpumask = cpumask_of(smp_processor_id()); 


Remember that we have set the cpumask of the at91sam926x periodic timer to first 
processor. If the cpumask field is zero, we check the number of possible processors in the 
system and print warning message if it is less than on. Additionally we set the cpumask of 
the given clock event device to the current processor. If you are interested in how the 

smp_processor_id macro is implemented, you can read more about it in the fourth part of the 
Linux kernel initialization process chapter. 


After this check we lock the actual code of the clock event device registration by the call 
following macros: 


raw_spin_lock_irqsave(&clockevents_lock, flags); 


raw_spin_unlock_irgrestore(&clockevents_lock, flags); 


Additionally the raw_spin_lock_irqsave and the raw_spin_unlock_irqrestore macros disable 
local interrupts, however interrupts on other processors still may occur. We need to do it to 
prevent potential deadlock if we adding new clock event device to the list of clock event 
devices and an interrupt occurs from other clock event device. 


We can see following code of clock event device registration between the 


raw_spin_lock_irqsave and raw_spin_unlock_irgrestore macros: 


list_add(&dev->list, &clockevent_devices) ; 
tick_check_new_device(dev); 
clockevents_notify_released(); 


First of all we add the given clock event device to the list of clock event devices which is 
represented by the clockevent_devices : 


static LIST_HEAD(clockevent_devices); 


At the next step we call the tick_check_new_device function which is defined in the 

kernel/time/tick-common.c source code file and checks do the new registered clock event 

device should be used or not. The tick_check_new_device function checks the given 
clock_event_device gets the current registered tick device which is represented by the 
tick_device structure and compares their ratings and features. Actually 


CLOCK_EVT_STATE_ONESHOT is preferred: 


static bool tick_check_preferred(struct clock_event_device *curdev, 
struct clock_event_device *newdev) 


if (!(newdev->features & CLOCK_EVT_FEAT_ONESHOT)) { 
if (curdev && (curdev->features & CLOCK_EVT_FEAT_ONESHOT ) ) 
return false; 
if (tick_oneshot_mode_active()) 
return false; 


return !curdev || 
newdev->rating > curdev->rating || 
!cpumask_equal(curdev->cpumask, newdev->cpumask); 


If the new registered clock event device is more preferred than old tick device, we exchange 
old and new registered devices and install new device: 


clockevents_exchange_device(curdev, newdev); 
tick_setup_device(td, newdev, cpu, cpumask_of(cpu)); 


The clockevents_exchange_device function releases or in other words deleted the old clock 
event device from the clockevent_devices list. The next function - tick_setup_device as we 
may understand from its name, setups new tick device. This function check the mode of the 


new registered clock event device and call the tick_setup_periodic function or the 
tick_setup_oneshot depends on the tick device mode: 


if (td->mode == TICKDEV_MODE_PERIODIC) 
tick_setup_periodic(newdev, 0); 

else 
tick_setup_oneshot(newdev, handler, next_event); 


Both of this functions calls the clockevents_switch_state to change state of the clock event 
device and the clockevents_program_event function to set next event of clock event device 
based on delta between the maximum and minimum difference current time and time for the 
next event. The tick_setup_periodic : 


clockevents_switch_state(dev, CLOCK_EVT_STATE_PERIODIC); 
clockevents_program_event(dev, next, false)) 


and the tick_setup_oneshot_periodic 


clockevents_switch_state(newdev, CLOCK_EVT_STATE_ONESHOT) ; 
clockevents_program_event(newdev, next_event, true); 


The clockevents_switch_state function checks that the clock event device is not in the 
given state and calls the _ clockevents_switch_state function from the same source code 
file: 


if (clockevent_get_state(dev) != state) { 
if (__clockevents_switch_state(dev, state)) 
return; 


The _clockevents_switch_state function just makes a call of the certain callback depends 
on the given state: 


static int _ clockevents_switch_state(Struct clock_event_device *dev, 
enum clock_event_state state) 


if (dev->features & CLOCK_EVT_FEAT_DUMMY) 
return 0; 


switch (state) { 
case CLOCK_EVT_STATE_DETACHED: 
case CLOCK_EVT_STATE_SHUTDOWN : 
if (dev->set_state_shutdown) 
return dev->set_state_shutdown(dev); 
return 0; 


case CLOCK_EVT_STATE_PERIODIC: 
if (!(dev->features & CLOCK_EVT_FEAT_PERIODIC)) 
return -ENOSYS; 
if (dev->set_state_periodic) 
return dev->set_state_periodic(dev); 
return 0; 


In our case for at91sam926x periodic timer, the state is the CLOCK_EVT_FEAT_PERIODIC : 


data->clkevt.features = CLOCK_EVT_FEAT_PERIODIC; 
data->clkevt.set_state_periodic = pit_clkevt_set_periodic; 


So, for the pit_clkevt_set_periodic callback will be called. If we will read the 
documentation of the Periodic Interval Timer (PIT) for at91sam926x, we will see that there is 
Periodic Interval Timer Mode Register which allows us to control of periodic interval timer. 


It looks like: 
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Where piv or Periodic Interval value - defines the value compared with the primary 20- 
bit counter of the Periodic Interval Timer. The PITEN Or Period Interval Timer Enabled if 
the bitis 1 andthe PITIEN or Periodic Interval Timer Interrupt Enable if the bitis 1 
So, to set periodic mode, we need to set 24, 25 bits inthe Periodic Interval Timer Mode 
Register . And we are doing it inthe pit_clkevt_set_periodic function: 


static int pit_clke set_periodic(struct clock_event_device *dev) 


{ 
struct pit data *data = clkevt_to_pit_data(dev); 


pit_write(data->base, AT91_PIT_MR, 
(data->cycle - 1) | AT91_PIT_PITEN | AT91_PIT_PITIEN); 


return 0; 


Where the AT91 PT MR , AT91_PT_PITEN andthe AT91_PIT_PITIEN are declared as: 


#define AT91_PIT_MR 0x00 
#define AT91_PIT_PITIEN BIT(25) 
#define AT91_PIT_PITEN BIT(24) 


After the setup of the new clock event device is finished, we can return to the 
clockevents_register_device function. The last function in the clockevents_register_device 
function is: 


clockevents_notify_released(); 


This function checks the clockevents_released list which contains released clock event 

devices (remember that they may occur after the call of the clockevents_exchange_device 

function). If this list is not empty, we go through clock event devices from the 
clock_events_released list and delete it from the clockevent_devices : 


static void clockevents_notify_released(void) 


{ 


struct clock_event_device *dev; 


while (!list_empty(&clockevents_released)) { 
dev = list_entry(clockevents_released.next, 
struct clock_event_device, list); 
list_del(&dev->list); 
list_add(&dev->list, &clockevent_devices) ; 
tick_check_new_device(dev); 


That's all. From this moment we have registered new clock event device. So the usage of 
the clockevents framework is simple and clear. Architectures registered their clock event 
devices, in the clock events core. Users of the clockevents core can get clock event devices 
for their use. The clockevents framework provides notification mechanisms for various 
clock related management events like a clock event device registered or unregistered, a 
processor is offlined in system which supports CPU hotplug and etc. 


We saw implementation only of the clockevents_register_device function. But generally, the 

clock event layer AP! is small. Besides the API for clock event device registration, the 
clockevents framework provides functions to schedule the next event interrupt, clock event 

device notification service and support for suspend and resume for clock event devices. 


If you want to Know more about clockevents API you can start to research following source 
code and header files: kernel/time/tick-common.c, kernel/time/clockevents.c and 
include/linux/clockchips.h. 


That's all. 


Conclusion 


This is the end of the fifth part of the chapter that describes timers and timer management 
related stuff in the Linux kernel. In the previous part got acquainted with the timers 
concept. In this part we continued to learn time management related stuff in the Linux kernel 


and saw a little about yet another framework - clockevents . 


If you have questions or suggestions, feel free to ping me in twitter OxAX, drop me email or 
just create issue. 


Please note that English is not my first language and | am really sorry for any 
inconvenience. If you found any mistakes please send me PR to linux-insides. 
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Timers and time management in the Linux 
kernel. Part 6. 


x86_64 related clock sources 


This is sixth part of the chapter which describes timers and time management related stuff in 
the Linux kernel. In the previous part we saw clockevents framework and now we will 
continue to dive into time management related stuff in the Linux kernel. This part will 
describe implementation of x86 architecture related clock sources (more about clocksource 
concept you can read in the second part of this chapter). 


First of all we must know what clock sources may be used at x86 architecture. It is easy to 
know from the sysfs or from content of the 
/sys/devices/system/clocksource/clocksource@/available_clocksource . The 


/sys/devices/system/clocksource/clocksourceN provides two special files to achieve this: 


e available_clocksource - provides information about available clock sources in the 
system; 

e current_clocksource - provides information about currently used clock source in the 
system. 


So, let's look: 


$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
tsc hpet acpi_pm 


We can see that there are three registered clock sources in my system: 


e tsc - Time Stamp Counter; 
è hpet - High Precision Event Timer; 
e acpi_pm - ACPI Power Management Timer. 


Now let's look at the second file which provides best clock source (a clock source which has 
the best rating in the system): 


$ cat /sys/devices/system/clocksource/clocksourceO0/current_clocksource 
tsc 


For me it is Time Stamp Counter. As we may know from the second part of this chapter, 
which describes internals of the clocksource framework in the Linux kernel, the best clock 
source in a system is a clock source with the best (highest) rating or in other words with the 
highest frequency. 


Frequency of the ACP! power management timer is 3.579545 MHz . Frequency of the High 
Precision Event Timer is atleast 10 MHz . And the frequency of the Time Stamp Counter 
depends on processor. For example On older processors, the Time Stamp Counter was 
counting internal processor clock cycles. This means its frequency changed when the 
processor's frequency scaling changed. The situation has changed for newer processors. 
Newer processors have an invariant Time Stamp counter that increments at a constant rate 
in all operational states of processor. Actually we can get its frequency in the output of the 
/proc/cpuinfo . For example for the first processor in the system: 


$ cat /proc/cpuinfo 


model name : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz 


And although Intel manual says that the frequency of the Time stamp Counter , while 
constant, is not necessarily the maximum qualified frequency of the processor, or the 
frequency given in the brand string, anyway we may see that it will be much more than 
frequency of the acpr pm timer or High Precision Event Timer . And we can see that the 
clock source with the best rating or highest frequency is current in the system. 


You can note that besides these three clock source, we don't see yet another two familiar us 
clock sources in the output of the 

/sys/devices/system/clocksource/clocksource@/available_clocksource . These clock sources 
are jiffy and refined_jiffies . We don't see them because this filed maps only high 
resolution clock sources or in other words clock sources with the 
CLOCK_SOURCE_VALID_FOR_HRES flag. 





As | already wrote above, we will consider all of these three clock sources in this part. We 
will consider it in order of their initialization or: 


e hpet ; 
e acpi_pm ; 


e tsc. 


We can make sure that the order is exactly like this in the output of the dmesg util: 


$ dmesg | grep clocksource 

[ 0.000000] clocksource: refined-jiffies: mask: Oxffffffff max_cycles: OxfffffffFf, 

max_idle_ns: 1910969940391419 ns 

[ 0.000000] clocksource: hpet: mask: Oxffffffff max_cycles: Oxffffffff, max_idle_ns 
: 133484882848 ns 

[ 0.094369] clocksource: jiffies: mask: Oxffffffff max_cycles: Oxffffffff, max_idle 

_ns: 1911260446275000 ns 

[ 0.186498] clocksource: Switched to clocksource hpet 

[ 0.196827] clocksource: acpi_pm: mask: Oxffffff max_cycles: Oxffffff, max_idle_ns: 
2085701024 ns 

[ 1.413685] tsc: Refined TSC clocksource calibration: 3999.981 MHz 

[ 1.413688] clocksource: tsc: mask: QOxffffffffffffffff max_cycles: 0x73509721780, m 

ax_idle_ns: 881591102108 ns 

[ 2.413748] clocksource: Switched to clocksource tsc 


The first clock source is the High Precision Event Timer, so let's start from it. 


High Precision Event Timer 


The implementation of the High Precision Event Timer for the x86 architecture is located in 
the arch/x86/kernel/hpet.c source code file. Its initialization starts from the call of the 

hpet_enable function. This function is called during Linux kernel initialization. If we will look 
into start_kernel function from the init/main.c source code file, we will see that after the all 
architecture-specific stuff initialized, early console is disabled and time management 
subsystem already ready, call of the following function: 


if (late_time_init) 
late_time_init(); 


which does initialization of the late architecture specific timers after early jiffy counter already 
initialized. The definition of the late time init function for the x86 architecture is located 
in the arch/x86/kernel/time.c source code file. It looks pretty easy: 


static _init void x86_late_time_init(void) 
{ 
x86_init.timers.timer_init(); 
tsc_init(); 


As we may see, it does initialization of the x86 related timer and initialization of the Time 
Stamp Counter . The seconds we will see in the next paragraph, but now let's consider the 
call of the x86_init.timers.timer_init function. The timer_init points to the 


hpet_time_init function from the same source code file. We can verify this by looking on 
the definition of the x86_init structure from the arch/x86/kernel/x86_ init.c: 


struct x86_init_ops x86_init __initdata = { 


.timers = { 


.setup_percpu_clockev = setup_boot_APIC_clock, 
.timer_init = hpet_time_init, 
-wallclock_init = x86_init_noop, 


}, 


The hpet_time_init function does setup of the programmable interval timer if we can not 
enable High Precision Event Timer and setups default timer IRQ for the enabled timer: 


void _ init hpet_time_init(void) 
{ 
if (!hpet_enable()) 
setup_pit_timer(); 
setup_default_timer_irq(); 


First of all the hpet_enable function check we can enable High Precision Event Timer in 
the system by the call of the is_hpet_capable function and if we can, we map a virtual 
address space for it: 


int init hpet_enable(void) 


{ 
if (!is_hpet_capable()) 
return 0; 
hpet_set_mapping(); 
} 


The is_hpet_capable function checks that we didn't pass hpet=disable to the kernel 
command line and the hpet_address is received from the ACP! HPET table. The 
hpet_set_mapping function just maps the virtual address spaces for the timer registers: 


hpet_virt_address = ioremap_nocache(hpet_address, HPET_MMAP_SIZE); 


As we can read in the IA-PC HPET (High Precision Event Timers) Specification: 


The timer register space is 1024 bytes 


So, the HPET_MMAP_SIZE is 1024 bytes too: 


#define HPET_MMAP_SIZE 1024 


After we mapped virtual space for the High Precision Event Timer , we read HPET_ID 
register to get number of the timers: 


id = hpet_read1(HPET_ID); 


last = (id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT; 


We need to get this number to allocate correct amount of space for the General 


Configuration Register of the High Precision Event Timer : 


cfg = hpet_readl(HPET_CFG) ; 


hpet_boot_cfg = kmalloc((last + 2) * sizeof(*hpet_boot_cfg), GFP_KERNEL); 


After the space is allocated for the configuration register of the High Precision Event Timer , 
we allow to main counter to run, and allow timer interrupts if they are enabled by the setting 

of HPET_CFG_ENABLE bit in the configuration register for all timers. In the end we just register 

new clock source by the call of the hpet_clocksource_register function: 


if (hpet_clocksource_register() ) 
goto out_nohpet; 


which just calls already familiar 


clocksource_register_hz(&clocksource_hpet, (u32)hpet_freq); 


function. Where the clocksource_hpet is the clocksource structure with the rating 250 
(remember rating of the previous refined_jiffies clock source was 2 ),name- hpet and 
read_hpet callback for the reading of atomic counter provided by the High Precision Event 


Timer : 


static struct clocksource clocksource_hpet = { 


. name = "hpet", 

.rating = 250, 

.read = read_hpet, 

.mask = HPET_MASK, 

.flags = CLOCK_SOURCE_IS_CONTINUOUS, 

. resume = hpet_resume_counter, 
.archdata = { .vclock_mode = VCLOCK_HPET }, 


}; 


After the clocksource_hpet is registered, we can return to the hpet_time_init() function 
from the arch/x86/kernel/time.c source code file. We can remember that the last step is the 
call of the: 


setup_default_timer_irq(); 


function in the hpet_time_init() . The setup_default_timer_irg function checks existence 
of legacy IRQs or in other words support for the i8259 and setups !RQO depends on this. 


That's all. From this moment the High Precision Event Timer clock source registered in the 
Linux kernel clock source framework and may be used from generic kernel code via the 


read_hpet : 


static cycle_t read_hpet(struct clocksource *cs) 


{ 
return (cycle t)hpet_readl(HPET_COUNTER); 


function which just reads and returns atomic counter from the main Counter Register . 


ACPI PM timer 


The seconds clock source is ACP! Power Management Timer. Implementation of this clock 
source is located in the drivers/clocksource/acpi_pm.c source code file and starts from the 
call of the init_acpi_pm_clocksource function during fs initcall. 


If we will look at implementation of the init_acpi_pm_clocksource function, we will see that it 
starts from the check of the value of pmtmr_ioport variable: 


static int __init init_acpi_pm_clocksource(void) 


{ 


if (!pmtmr_ioport) 
return -ENODEV; 


This pmtmr_ioport variable contains extended address of the Power Management Timer 
Control Register Block . It gets its value in the acpi_parse_fadt function which is defined in 
the arch/x86/kernel/acpi/boot.c source code file. This function parses FADT or Fixed ACPI 
Description Table ACPI table and tries to get the values of the x_pm_tmr_BLK field which 
contains extended address of the Power Management Timer Control Register Block 
represented in Generic Address Structure format: 


static int Init acpi_parse_fadt(struct acpi table header *table) 
{ 
#ifdef CONFIG_X86_PM_TIMER 


pmtmr_ioport = acpi_gbl_FADT.xpm_timer_block.address; 


#endif 
return 0; 


So, if the coNFIG x86_PM_TIMER Linux kernel configuration option is disabled or something 
going wrong inthe acpi_parse_fadt function, we can't access the Power Management Timer 
register and return from the init_acpi_pm_clocksource . In other way, if the value of the 

pmtmr_ioport variable is not zero, we check rate of this timer and register this clock source 
by the call of the: 


clocksource_register_hz(&clocksource_acpi_pm, PMTMR_TICKS_PER_SEC); 


function. After the call of the clocksource_register_hs , the acpi_pm clock source will be 
registered in the clocksource framework of the Linux kernel: 


static struct clocksource clocksource_acpi_pm = { 


. name = "acpi_pm", 

.rating = 200, 

.read = acpi_pm_read, 

.mask = (cycle_t)ACPI_PM_MASK, 
.flags = CLOCK_SOURCE_IS_CONTINUOUS, 


}; 


with the rating - 200 andthe acpi_pm_read callback to read atomic counter provided by the 
acpi_pm clock source. The acpi_pm_read function just executes read_pmtmr function: 


static cycle_t acpi_pm_read(struct clocksource *cs) 


{ 


return (cycle_t)read_pmtmr(); 


which reads value of the Power Management Timer register. This register has following 
structure: 


TA E 二 十 


running count of the 


power management timer 


| 
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Address of this register is stored in the Fixed ACPI Description Table ACP! table and we 
already have it in the pmtmr_ioport . So, the implementation of the read_pmtmr function is 
pretty easy: 


static inline u32 read_pmtmr(void) 


{ 
return inl(pmtmr_ioport) & ACPI_PM_MASK; 


We just read the value of the Power Management Timer register and mask its 24 bits. 


That's all. Now we move to the last clock source in this part- Time Stamp Counter . 


Time Stamp Counter 


The third and last clock source in this part is - Time Stamp Counter clock source and its 
implementation is located in the arch/x86/kernel/tsc.c source code file. We already saw the 

x86_late_time_init function in this part and initialization of the Time Stamp Counter starts 
from this place. This function calls the tsc_init() function from the arch/x86/kernel/tsc.c 
source code file. 


At the beginning of the tsc_init function we can see check, which checks that a processor 
has support of the Time Stamp Counter : 


void __init tsc_init(void) 
{ 

u64 1pj; 

int cpu; 


if (!cpu_has_tsc) { 
setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER); 
return; 


The cpu_has_tsc macro expands to the call of the cpu_has macro: 


#define cpu_has_tsc boot_cpu_has(X86_FEATURE_TSC) 
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit) 


#define cpu_has(c, bit) \ 
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : N 
test_cpu_cap(c, bit)) 


which check the given bit (the x86_FEATURE_ TSC_ DEADLINE_TIMER in our case) in the 

boot_cpu_data array which is filled during early Linux kernel initialization. If the processor 
has support of the Time Stamp Counter , we get the frequency of the Time Stamp Counter by 
the call of the calibrate_tsc function from the same source code file which tries to get 
frequency from the different source like Model Specific Register, calibrate over 
programmable interval timer and etc, after this we initialize frequency and scale factor for the 
all processors in the system: 


tsc_khz 
cpu_khz = tsc_khz; 


x86_platform.calibrate_tsc(); 


for_each_possible_cpu(cpu) { 
cyc2ns_init(cpu); 
set_cyc2ns_scale(cpu_khz, cpu); 


because only first bootstrap processor will call the tsc_init . After this we check hat Time 
Stamp Counter is not disabled: 


if (tsc_disabled > 0) 


return; 


check_system_tsc_reliable(); 


and call the check_system_tsc_reliable function which sets the tsc_clocksource_reliable if 
bootstrap processor has the x86_FEATURE_TSC_RELIABLE feature. Note that we went through 
the tsc_init function, but did not register our clock source. Actual registration of the Time 
Stamp Counter Clock source occurs in the: 


static int __init init_tsc_clocksource(void) 
{ 
if (!cpu_has_tsc || tsc_disabled > 0 || !tsc_khz) 
return 0; 


if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE)) { 
clocksource_register_khz(&clocksource_tsc, tsc_khz); 
return 0; 


function. This function called during the device initcall. We do it to be sure that the Time 
Stamp Counter Clock source will be registered after the High Precision Event Timer clock 
source. 


After these all three clock sources will be registered in the clocksource framework and the 
Time Stamp Counter clock source will be selected as active, because it has the highest 
rating among other clock sources: 


static struct clocksource clocksource_tsc = { 


.name = "tsc", 
.rating = 300, 
.read = read tsc, 
.mask = CLOCKSOURCE_MASK(64), 
.flags = CLOCK_SOURCE_IS_CONTINUOUS | CLOCK_SOURCE_MUST_VERIFY, 
.archdata = { .vclock_mode = VCLOCK_TSC }, 
}; 
That's all. 
Conclusion 


This is the end of the sixth part of the chapter that describes timers and timer management 
related stuff in the Linux kernel. In the previous part got acquainted with the clockevents 
framework. In this part we continued to learn time management related stuff in the Linux 
kernel and saw a little about three different clock sources which are used in the x86 
architecture. The next part will be last part of this chapter and we will see some user space 
related stuff, i.e. how some time related system calls implemented in the Linux kernel. 


If you have questions or suggestions, feel free to ping me in twitter OxAX, drop me email or 
just create issue. 


Please note that English is not my first language and I am really sorry for any 
inconvenience. If you found any mistakes please send me PR to linux-insides. 
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Time related system calls in the Linux kernel 


This is the seventh and last part chapter which describes timers and time management 
related stuff in the Linux kernel. In the previous part we saw some x86_ 64 like High 
Precision Event Timer and Time Stamp Counter. Internal time management is interesting 
part of the Linux kernel, but of course not only the kernel needs in the time concept. Our 
programs need to know time too. In this part, we will consider implementation of some time 
management related system calls. These system calls are: 


© clock_gettime ; 
@ gettimeofday ; 


e nanosleep . 


We will start from simple userspace C program and see all way from the call of the standard 
library function to the implementation of certain system call. As each architecture provides its 
own implementation of certain system call, we will consider only x86_64 specific 
implementations of system calls, as this book is related to this architecture. 


Additionally we will not consider concept of system calls in this part, but only 
implementations of these three system calls in the Linux kernel. If you are interested in what 
is ita system call , there is special chapter about this. 


So, let's from the gettimeofday system call. 


Implementation of the gettimeofday system 
call 


As we can understand from the name of the gettimeofday , this function returns current 
time. First of all, let's look on the following simple example: 


#include <time.h> 
#include <sys/time.h> 
#include <stdio.h> 


int main(int argc, char **argv) 
{ 

char buffer[40]; 

struct timeval time; 


gettimeofday(&time, NULL); 


strftime(buffer, 40, "Current date/time: %m-%d-%Y/%T", localtime(&time.tv_sec)); 
printf("%s\n", buffer); 


return 0; 


As you can see, here we call the gettimeofday function which takes two parameters: 
pointer to the timeval structure which represents an elapsed tim: 


struct timeval { 
time_t tv_sec; 





suseconds_t tv_usec; /* micr 


}; 


The second parameter of the gettimeofday function is pointer to the timezone Structure 
which represents a timezone. In our example, we pass address of the timeval time to the 

gettimeofday function, the Linux kernel fills the given timeval structure and returns it back 
to us. Additionally, we format the time with the strftime function to get something more 
human readable than elapsed microseconds. Let's see on result: 


~$ gcc date.c -o date 
~$ ./date 
Current date/time: 03-26-2016/16:42:02 


As you already may know, an userspace application does not call a system call directly from 
the kernel space. Before the actual system call entry will be called, we call a function from 
the standard library. In my case it is glibc, so | will consider this case. The implementation of 
the gettimeofday function is located in the sysdeps/unix/sysv/linux/x86/gettimeofday.c 
source code file. As you already may know, the gettimeofday is not usual system call. It is 
located in the special area which is called vpso (you can read more about it in the part 
which describes this concept). 


The glibc implementation of the gettimeofday tries to resolve the given symbol, in our 
case this symbol is _ vdso_gettimeofday by the call of the _dl vdso_vsym internal function. 
If the symbol will not be resolved, it returns NULL and we fallback to the call of the usual 
system call: 


return (_dl_vdso_vsym ("__vdso_gettimeofday", &linux26) 
?: (void*) (& __gettimeofday_syscall)); 


The gettimeofday entry is located in the arch/x86/entry/vdso/vclock_gettime.c source code 
file. As we can see the gettimeofday is weak alias of the _ vdso_gettimeofday : 


int gettimeofday(struct timeval *, struct timezone *) 
__attribute__((weak, alias("__vdso_gettimeofday"))); 


The _ vdso gettimeofday is defined in the same source code file and calls the do_realtime 
function if the given timeval is not null: 


notrace int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz) 
{ 
if (likely(tv != NULL)) { 
If (unlikely(do_realtime((struct timespec *)tv) == VCLOCK_NONE) ) 
return vdso_fallback_gtod(tv, tz); 
tv->tv_usec /= 1000; 
} 
if (unlikely(tz != NULL)) { 
tz->tz_minuteswest = gtod->tz_minuteswest; 
tz->tz_dsttime = gtod->tz_dsttime; 


return o; 


If the do_realtime will fail, we fallback to the real system call via call the syscall 
instruction and passing the __NR_gettimeofday system call number and the given timeval 


and timezone 


notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz) 
{ 

long ret; 

asm("syscall" : "=a" (ret) 


"o" (__NR_gettimeofday), "D" (tv), "S" (tz) : "memory"); 
return ret; 


The do_realtime function gets the time data from the vsyscall_gtod_data structure which 

is defined in the arch/x86/include/asm/vgtod.h header file and contains mapping of the 
timespec structure and a couple of fields which are related to the current clock source in 

the system. This function fills the given timeval structure with values from the 
vsyscall_gtod_data which contains a time related data which is updated via timer interrupt. 


First of all we try to access the gtod or global time of day the vsyscall_gtod_data 
structure via the call of the gtod_read_begin and will continue to do it until it will be 
successful: 


do { 
seq = gtod_read_begin(gtod); 
mode = gtod->vclock_mode; 
ts->tv_sec = gtod->wall_time_sec; 
ns = gtod->wall_time_snsec; 
ns += vgetsns(&mode); 
ns >>= gtod->shift; 
} while (unlikely(gtod_read_retry(gtod, seq))); 





ts->tv_sec += iter_div_u64_rem(ns, NSEC_PER_SEC, &ns); 
ts->tv_nsec = ns; 


As we got access to the gtod , we fill the ts->tv_sec with the gtod->wall_time_sec which 
stores current time in seconds gotten from the real time clock during initialization of the 
timekeeping subsystem in the Linux kernel and the same value but in nanoseconds. In the 
end of this code we just fill the given timespec structure with the resulted values. 


That's all about the gettimeofday system call. The next system call in our list is the 


clock_gettime 


Implementation of the clock_gettime system 
call 


The clock_gettime function gets the time which is specified by the second parameter. 
Generally the clock_gettime function takes two parameters: 


e clk id - clock identifier; 
e timespec -address of the timespec structure which represent elapsed time. 


Let's look on the following simple example: 


#include <time.h> 

#include <sys/time.h> 

#include <stdio.h> 

int main(int argc, char **argv) 

{ 
struct timespec elapsed_from_boot; 
clock_gettime(CLOCK_BOOTTIME, &elapsed_from_boot); 


printf("%d - seconds elapsed from boot\n", elapsed_from_boot.tv_sec); 


return 0; 


which prints uptime information: 


~$ gcc uptime.c -o uptime 
~$ ./uptime 
14180 - seconds elapsed from boot 


We can easily check the result with the help of the uptime util: 


~$ uptime 
up 3:56 


The elapsed_from_boot.tv_sec represents elapsed time in seconds, so: 


>>> 14180 / 60 
>>> 14180 / 60 / 60 


>>> 14180 / 60 % 60 


The clock_id maybe one of the following: 


e CLOCK_REALTIME - System wide clock which measures real or wall-clock time; 

e CLOCK REALTIME COARSE - faster version of the CLOCK_REALTIME ; 

e CLOCK_MONOTONIC -represents monotonic time since some unspecified starting point; 

e CLOCK_MONOTONIC_coARSE -faster version of the crock MONOTONIC ; 

e CLOCK_MONOTONIC_RAW -the same as the cLock_monotonic but provides non NTP 
adjusted time. 

e CLOCK_BooTTIME -the same asthe cLock_monotonic but plus time that the system was 
suspended; 


e CLOCK_PROCESS_CPUTIME_ID - per-process time consumed by all threads in the process; 


© CLOCK_THREAD_CPUTIME_ID - thread-specific clock. 


The clock_gettime is not usual syscall too, but as the gettimeofday , this system call is 
placed in the vpso area. Entry of this system call is located in the same source code file - 
arch/x86/entry/vdso/vclock_gettime.c) as for gettimeofday . 


The Implementation of the clock_gettime depends on the clock id. If we have passed the 
CLOCK_REALTIME Clock id, the do_realtime function will be called: 


notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts) 
{ 
switch (clock) { 
case CLOCK_REALTIME: 
if (do_realtime(ts) == VCLOCK_NONE) 
goto fallback; 
break; 


fallback: 
return vdso_fallback_gettime(clock, ts); 


In other cases, the do_{name_of_clock_id} function is called. Implementations of some of 





them is similar. For example if we will pass the cLock_monotontc clock id: 


case CLOCK_MONOTONIC: 
if (do_monotonic(ts) == VCLOCK_NONE) 
goto fallback; 
break; 


the do_monotonic function will be called which is very similar on the implementation of the 


do_realtime 


notrace static int __always_inline do_monotonic(struct timespec 





{ 
do { 
seq = gtod_read_begin(gtod); 
mode = gtod->vclock_mode; 
ts->tv_sec = gtod->monotonic_time_sec; 
ns = gtod->monotonic_time_snsec; 
ns += vgetsns(&mode); 
ns >>= gtod->shift; 
} while (unlikely(gtod_read_retry(gtod, seq))); 
ts->tv_sec += iter_div_u64_rem(ns, NSEC_PER_SEC, &ns); 
ts->tv_nsec = ns; 
return mode; 
} 


SESI) 


We already saw a little about the implementation of this function in the previous paragraph 


about the gettimeofday . There is only one difference here, that the sec and nsec of our 


timespec Value will be based on the gtod->monotonic_time_sec instead of gtod- 


>wall_time_sec which maps the value of the tk->tkr_mono.xtime_nsec or number of 


nanoseconds elapsed. 


That's all. 


Implementation of the nanosleep system call 


The last system call in our list is the nanosleep . As you can understand from its name, this 


function provides sleeping ability. Let's look on the following simple example: 


#include <time.h> 
#include <stdlib.h> 
#include <stdio.h> 


int main (void) 

{ 
struct timespec ts = {5,0}; 
printf("sleep five seconds\n"); 
nanosleep(&ts, NULL); 


prantf (“end of sleep\n™); 


return 0; 


If we will compile and run it, we will see the first line 


~$ gcc sleep_test.c -0 sleep 
~$ ./sleep 

sleep five seconds 

end of sleep 


and the second line after five seconds. 


The nanosleep is not located inthe vpso area like the gettimeofday and the 
clock_gettime functions. So, let's look how the real system call which is located in the 
kernel space will be called by the standard library. The implementation of the nanosleep 
system call will be called with the help of the syscall instruction. Before the execution of the 
syscall instruction, parameters of the system call must be put in processor registers 
according to order which is described in the System V Application Binary Interface or in 
other words: 


e rdi -first parameter; 

èe rsi -second parameter; 
e rdx -third parameter; 

e r10 -fourth parameter; 
e rs -fifth parameter; 

e rg -sixth parameter. 


The nanosleep system call has two parameters - two pointers to the timespec structures. 
The system call suspends the calling thread until the given timeout has elapsed. Additionally 
it will finish if a signal interrupts its execution. lt takes two parameters, the first is timespec 
which represents timeout for the sleep. The second parameter is the pointer to the 

timespec structure too and it contains remainder of time if the call of the nanosleep was 
interrupted. 


AS nanosleep has two parameters: 


int nanosleep(const struct timespec *req, struct timespec *rem); 


To call system call, we need put the req tothe rdi register,and the rem parameter to 
the rsi register. The glibc does these job inthe INTERNAL_SYSCALL macro which is located 
in the sysdeps/unix/sysv/linux/x86_64/sysdep.h header file. 


# define INTERNAL_SYSCALL(name, err, nr, args...) \ 
INTERNAL_SYSCALL_NCS (__NR_##name, err, nr, ##args) 


which takes the name of the system call, storage for possible error during execution of 
system call, number of the system call (all x86 64 system calls you can find in the system 
calls table) and arguments of certain system call. The INTERNAL_SYSCALL macro just expands 
to the call of the InTERNAL_SYSCALL_NCS macro, which prepares arguments of system call 
(puts them into the processor registers in correct order), executes syscall instruction and 
returns the result: 


# define INTERNAL_SYSCALL_NCS(name, err, nr, args...) \ 
({ \ 

unsigned long int resultvar; 

LOAD_ARGS_##nr (args) \ 

LOAD_REGS_##nr \ 

asm volatile ( N 

"syscall\n\t" \ 
"=a" (resultvar) N 
"0" (name) ASM_ARGS_##nr : "memory", REGISTERS_CLOBBERED_BY_SYSCALL); \ 

(long int) resultvar; }) 


The LoAD_ARGS_##nr macro calls the LOAD_ARGS_N macro where the n is number of 
arguments of the system call. In our case, it will be the Loap_ARcs_2 macro. Ultimately all of 
these macros will be expanded to the following: 


# define LOAD_REGS TYPES 1(t1, a1) \ 
register t1 _a1 asm ("rdi") = __arg1; \ 
LOAD_REGS_0O 

# define LOAD_REGS_TYPES_2(t1, ai, t2, a2) \ 
register t2 _a2 asm ("rsi") = __arg2; \ 


LOAD_REGS_TYPES_1(t1, a1) 


After the syscall instruction will be executed, the context switch will occur and the kernel 

will transfer execution to the system call handler. The system call handler for the nanosleep 

system call is located in the kernel/time/hrtimer.c source code file and defined with the 
SYSCALL_DEFINE2 macro helper: 


SYSCALL_DEFINE2(nanosleep, struct timespec __user *, rqtp, 
struct timespec __user *, rmtp) 


struct timespec tu; 


if (copy_from_user(&tu, rqtp, sizeof(tu))) 
return -EFAULT; 


if (!timespec_valid(&tu) ) 
return -EINVAL; 


return hrtimer_nanosleep(&tu, rmtp, HRTIMER_MODE_REL, CLOCK_MONOTONIC); 


More about the syscaLL_DEFINE2 macro you may read in the chapter about system calls. If 

we look at the implementation of the nanosleep system call, first of all we will see that it 

starts from the call of the copy from user function. This function copies the given data from 

the userspace to kernelspace. In our case we copy timeout value to sleep to the kernelspace 
timespec structure and check that the given timespec is valid by the call of the 
timesc_valid function: 


static inline bool timespec_valid(const struct timespec *ts) 
{ 
if (ts->tv_sec < 0) 
return false; 
if ((unsigned long)ts->tv_nsec >= NSEC_PER_SEC) 
return false; 
return true; 


which just checks that the given timespec does not represent date before 1970 and 
nanoseconds does not overflow 1 second. The nanosleep function ends with the call of 
the hrtimer_nanosleep function from the same source code file. The hrtimer_nanosleep 
function creates a timer and calls the do_nanosleep function. The do_nanosleep does main 
job for us. This function provides loop: 


do { 
set_current_state(TASK_INTERRUPTIBLE) ; 
hrtimer_start_expires(&t->timer, mode); 


if (likely(t->task) ) 
freezable_schedule(); 


} while (t->task && !signal_pending(current)); 


__set_current_state(TASK_RUNNING); 
return t->task == NULL; 


Which freezes current task during sleep. After we set TASK_INTERRUPTIBLE flag for the 
current task, the hrtimer_start_expires function starts the give high-resolution timer on the 
current processor. As the given high resolution timer will expire, the task will be again 
running. 


That's all. 


Conclusion 


This is the end of the seventh part of the chapter that describes timers and timer 
management related stuff in the Linux kernel. In the previous part we saw x86_64 specific 
clock sources. As | wrote in the beginning, this part is the last part of this chapter. We saw 
important time management related concepts like clocksource and clockevents 
frameworks, jiffies counter and etc., in this chpater. Of course this does not cover all of 
the time management in the Linux kernel. Many parts of this mostly related to the scheduling 
which we will see in other chapter. 


If you have questions or suggestions, feel free to ping me in twitter OxAX, drop me email or 
just create issue. 


Please note that English is not my first language and I am really sorry for any 
inconvenience. If you found any mistakes please send me PR to linux-insides. 
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© 自 旋 锁 简介 -这 
© 队列 自 旋 锁 - 第 二 
e 信号 量 -this part describes impmentation of semaphore synchronization primitive in the 


节 的 第 一 部 分 描述 Linux 内 核 中 自 旋 锁 机 制 的 实现 ; 
部 分 描述 自 旋 锁 的 另 一 种 类 型 - 队列 自 旋 锁 ; 


Je 


个 章 
立 | 


Linux kernel. 这 个 部 分 描述 Linux 内 核 中 的 同步 原 语 semaphore 的 实现 ; 


e ZFA - 这 个 部 分 描述 Linux 内 核 中 的 mutex ; 
e 读者 / 写 We 号 量 - 这 个 部 分 描述 特殊 类 型 的 信号 量 - reader/writer 信号 量 ; 
e 顺序 销 - 这 个 部 分 描述 Linux 内 核 中 的 顺序 锁 . 


a 


Linux 内 核 中 的 同步 原 语 . 第 一 部 分 . 


Introduction 


这 一 部 分 为 linux-insides 这 本 书 开启 了 新 的 章节 。 定 时 器 和 时 间 管 理 相 关 的 概念 在 上 一 个 章 
节 已 经 描述 过 了 。 现 在 是 时 候 继续 了 。 就 像 你 可 能 从 这 一 部 分 的 标题 所 了 解 的 那样 ， 本 章节 
将 会 描述 Linux 内 核 中 的 同步 原 语 。 


像 往常 一 样 ， 在 考虑 一 些 同步 相关 的 事情 之 前 ， 我 们 会 党 试 去 概括 地 了 解 什 么 是 同步 原 语 。 事 
实 上 ， 同 步 原 语 是 一 种 软件 机 制 ， 提 供 了 两 个 或 者 多 个 并 行进 程 或 者 线程 在 不 同时 刻 执 行 一 
段 相同 的 代码 段 的 能 力 。 例 如 下 面 的 代码 片段 : 


mutex_lock(&clocksource_mutex); 


clocksource_enqueue(cs); 
clocksource_enqueue_watchdog(cs); 
clocksource_select(); 


mutex_unlock(&clocksource_mutex) ; 


出 自 kernel/time/clocksource.c 源 文 件 。 这 段 代 码 来 自 于 _clocksource_register_scale % 
数 ， 此 函数 添加 给 定 的 clocksource 到 时 钟 源 列表 中 。 这 个 函数 在 注册 时 钟 源 列表 中 生成 两 个 
不 同 的 操作 。 例如 clocksource_enqueue 函数 就 是 添加 给 定时 钟 源 到 注册 时 钟 源 列表 
clocksource_list 中 。 注 意 这 几 行 代码 被 两 个 函数 所 包围 : mutex_lock 和 

mutex_unlock ， 这 两 个 函数 都 带 有 一 个 参数 一 一 在 本 例 中 为 clocksource mutex ° 





这 些 函 数 展 示 了 基于 互 斤 锁 (mutex) 同步 原 语 的 加 锁 和 解锁 。 当 mutex_lock 被 执行 ， 人 允许 我 
们 阻止 两 个 或 两 个 以 上 线程 执行 这 段 代码 ， 而 mute_unlock 的 处 理 拥有 者 锁 
执行 。 换 名 话说 ， 就 是 阻止 在 clocksource_list 上 的 并 行 操作 。 为 什么 在 这 里 需要 使 用 互 乒 
锁 ? 如 果 两 个 并 行 处 理 尝 试 去 注册 一 个 时 钟 源 会 怎样 。 正 如 我 们 已 经 知道 的 那样 ， 其 中 具有 
最 大 的 等 级 【其 具有 最 高 的 频率 在 系 统 中 注册 的 时 钟 源 ) 的 列表 中 选择 一 个 时 钟 源 
后 ， clocksource _enqueue 函数 立即 将 一 个 给 定 的 时 钟 源 到 clocksource_list 列表 : 


static void clocksource_enqueue(struct clocksource *cs) 


{ 
struct list_head *entry = &clocksource_list; 
struct clocksource *tmp; 


list_for_each_entry(tmp, &clocksource_list, list) 
if (tmp->rating >= cs->rating) 
entry = &tmp->list; 
list_add(&cs->list, entry); 


如 果 两 个 并 行 处 理 尝试 同时 去 执行 这 个 函数 ， 那 么 这 两 个 处 理 可 能 会 找到 相同 的 入 口 
(entry) 可 能 发 生 竞 态 条 件 (race condition) 或 者 换 句 话说 ， 第 二 个 执行 list_add 的 处 理 程 
序 ， 将 会 重 写 第 一 个 线程 写 入 的 时 钟 源 。 


除了 这 个 简 答 的 例子 ， 同 步 原 语 在 Linux 内 核 无 处 不 在 。 如 果 再 翻阅 之 前 的 [章节 ] 
(https://xinqiu.gitbooks.io/linux-insides-cn/content/Timers/index.html) 或 者 其 他 章节 或 者 如 果 
大 概 看 看 Linux 内 核 源码 ， 就 会 发 现 许多 地 方 都 使 用 同步 原 语 。 我 们 不 考虑 mutex Æ Linux 
内 核 是 如 何 实 现 的 。 事 实 上 ，Linux 内 核 提 供 了 一 系列 不 同 的 同步 原 语 : 


@ mutex ; 
@ semaphores ; 
e seqlocks ; 


@ atomic operations ; 


KE KE 


。 等 等 。 


现在 从 自 族 锁 (spinlock) 这 个 章节 开始 。 


Linux 内 核 中 的 自 旋 锁 。 


自 旋 锁 简 单 来 说 是 一 种 低级 的 同步 机 制 ， 表 示 了 一 个 变量 可 能 的 两 个 状态 : 


@ acquired ; 


© released. 


每 一 个 想 要 获取 自 旋 锁 的 处 理 ， 必 须 为 这 个 变量 写 入 一 个 表示 自 旋 锁 获取 (spinlock 

acquire) 状态 的 值 ， 并 且 为 这 个 变量 写 入 锁 释 放 (spinlock released) 状态 。 如 果 一 个 处 理 程 
序 尝试 执行 受 ae 保护 的 代码 ， 那 么 代码 将 会 被 锁 住 ， 直 到 占有 和 锁 的 处 理 程序 释放 掉 。 在 
本 例 中 ， 所 有 相关 的 操作 必须 是 原子 的 (atomic)， 来 阻止 竞 态 条 件 状 态 。 自 旋 锁 在 Linux 内 
核 中 使 用 spinlock_t 类 型 来 表示 。 如 果 我 们 查看 Linux 内 核 代 码 ， 我 们 会 看 到 ， 这 个 类 型 被 
广泛 地 (widely) 使 用 。 spinlock_t 的 定义 如 下 : 


typedef struct spinlock { 
union { 
struct raw_spinlock rlock; 


#ifdef CONFIG_DEBUG_LOCK_ALLOC 
# define LOCK_PADSIZE (offsetof(struct raw_spinlock, dep_map) ) 
struct { 
u8 __padding[LOCK_PADSIZE]; 
struct lockdep_map dep_map; 
J; 
#endif 
}; 
} spinlock_t; 


这 段 代 码 在 include/linux/spinlock_types.h 头 文件 中 定义 。 可 以 看 出 ， 它 的 实现 依赖 于 

CONFIG_DEBUG_LOCK_ALLOC 内 核 配 置 选项 这 个 状态 。 现 在 我 们 跳 过 这 一 块 ， 因 为 所 有 的 调试 相 
关 的 事情 都 将 会 在 这 一 部 分 的 最 后 。 所 以 ， 如 果 coNFIG_DEBUG_LOCK_ALLOC 内 核 配 置 选项 不 可 
Fl > ABA spinlock_t 则 包含 联合 体 (union)， 这 个 联合 体 有 一 个 字段 





raw_spinlock 


typedef struct spinlock { 
union { 
struct raw_spinlock rlock; 
J; 
} spinlock_t; 


raw_spinlock 结构 的 定义 在 相同 的 头 文 件 中 并 且 表 达 了 普通 (normal) 自 旋 锁 的 实现 。 让 我 
们 看 看 raw_spinlock 结构 是 如 何 定 义 的 : 


typedef struct raw_spinlock { 
arch_spinlock_t raw_lock; 

#ifdef CONFIG_GENERIC_LOCKBREAK 
unsigned int break_lock; 

#endif 

} raw_spinlock_t; 


这 里 的 arch_spinlock_t 表示 了 体系 结构 指定 的 自 旋 锁 实现 并 且 break_lock 字段 持 有 值 
一 一 为 1 ， 当 一 个 处 理 器 开始 等 待 而 锁 被 另 一 个 处 理 器 持 有 时 ， 使 用 的 对 称 多 处 理 器 (SMP) 
系统 的 例子 中 。 这 样 就 可 以 防止 长 时 间 加 锁 。 考 虑 本 书 的 x86 64 架构 ， 因 此 
arch_spinlock_t 被 定义 在 arch/x86/include/asm/spinlock_types.h 头 文件 中 ， 并 且 看 上 去 是 
这 样 : 


#ifdef CONFIG_QUEUED_SPINLOCKS 
#include <asm-generic/qspinlock_types.h> 
#else 
typedef struct arch_spinlock { 
union { 
__ticketpair_t head_tail; 
struct __raw_tickets { 
__ticket_t head, tail; 
} tickets; 
}; 


} arch_spinlock_t; 


正如 我 们 所 看 到 的 ， arch_spinlock 结构 的 定义 依赖 于 CONFIG_QUEUED_SPINLOCKS 内 核 配 置 选 
项 的 值 。 这 个 Linux 内 核 配置 选项 支持 使 用 队列 的 Be 。 这 个 自 旋 锁 的 特殊 类 型 替代 了 
acquired 和 released 原子 值 ， 在 队列 上 使 用 原子 操作 。 如 果 CONFIG_QUEUED_SPINLOCKS 
内 核 配 置 选 项 启动 ， 那 么 arch_spinlock_t 将 会 被 表示 成 如 下 的 结构 : 


typedef struct qspinlock { 
atomic_t val; 
} arch_spinlock_t; 


来 自 于 include/asm-generic/qspinlock_types.h 头 文 件 。 


目前 我 们 不 会 在 这 个 结构 上 停止 探索 ， 在 考虑 arch_spinlock 和 qspinlock 之 前 ， 先 看 看 自 
旋 锁 上 的 操作 。 Linux 内 核 在 自 旋 锁 上 提供 了 一 下 主要 的 操作 : 





e spin lock init 给 定 的 自 旋 锁 进行 初始 化 ; 
© spin_lock 一 一 获取 给 定 的 自 旋 锁 ; 
e spin_lock_bh 一 一 禁止 软件 中 断 并 且 获 取 给 定 的 自 旋 锁 。 


@ Spin lock_irqsave 和 Spin_ lock_ird 一 一 禁止 本 地 处 理 器 上 的 中 断 并 且 保 存 一 不 保存 
之 前 的 中 断 状态 的 标识 (flag) ; 

e spin unlock 一 一 释放 给 定 的 自 旋 锁 ; 

e spin_unlock_bh 一 一 释放 给 定 的 自 旋 锁 并 且 启 动 软件 中 断 ; 

e spin_is_locked -返回 给 定 的 自 旋 锁 MRA; 


KE KE 


e FF 
来 看 看 spin lock_init 宏 的 实现 。 就 如 我 已 经 写 过 的 一 样 ， 这 个 宏和 其 他 宏 定义 都 在 
头 


include/linux/spinlock.h 头 文件 里 ， 并 且 spin_lock_init 宏 如 下 所 示 : 


#define spin_lock_init(_lock) \ 

do { \ 
spinlock_check(_lock) ; \ 
raw_spin_lock_init(&(_lock) ->rlock); \ 


} while (0) 


正如 所 看 到 的 ， spin_lock_init 宏 有 一 个 Bka ， 执 行 两 步 操 作 : 检查 我 们 看 到 的 给 定 的 A 
旋 锁 和 执行 raw_spin_lock_init ° spinlock_check 的 实现 相当 简单 ， 实 现 的 函数 仅仅 返回 已 
知 的 自 旋 锁 的 raw_spinlock_t ， 来 确保 我 们 精确 获得 正常 (normal) 原生 自 旋 锁 : 


static _ always_inline raw_spinlock_t *spinlock_check(spinlock_t *lock) 


{ 


return &lock->rlock; 


raw_spin_lock_init Z: 





# define raw_spin_lock_init(lock) \ 

do { \ 
*(lock) = __RAW_SPIN_LOCK_UNLOCKED( lock); \ 

} while (0) \ 





用 __RAW_SPIN_LOCK_UNLOCKED 的 值 和 给 定 的 A sesh 赋值 给 给 定 的 raw_spinlock_t 。 就 像 我 们 
能 从 __RAW_SPIN_LOCK_UNLOCKED 宏 的 名 字 中 了 解 的 那样 ， 这 个 宏 为 给 定 的 aww 执行 初始 化 
操作 ， 并 且 将 锁 设 置 为 释放 (released) 状态 。 宏 的 定义 在 include/linux/spinlock_types.h 头 
文件 中 ， 并 且 扩 展 了 一 下 的 宏 : 





#define RAW_SPIN_LOCK_UNLOCKED(lockname ) \ 
(raw_spinlock_t) RAW_SPIN_LOCK_INITIALIZER(lockname) 








#define RAW_SPIN_LOCK_INITIALIZER(lockname) N 








{ \ 
.raw_lock = ARCH_SPIN_LOCK_UNLOCKED, N 
SPIN_DEBUG_INIT(lockname) \ 
SPIN_DEP_MAP_INIT(lockname) À 

} 


正如 之 前 所 写 的 一 样 ， 我 们 不 考虑 同步 原 语调 试 相关 的 东西 。 在 本 例 中 也 不 考虑 


SPIN_DEBUG_INIT 和 SPIN_DEP_MAP_INIT Re 于 是 __RAW_SPINLOCK_UNLOCKED 宏 被 扩展 成 : 


*(&(_lock)->rlock) = __ARCH_SPIN_LOCK_UNLOCKED; 





而 ARCH_SPIN_LOCK_UNLOCKED 宏 是 : 





#define __ARCH_SPIN_LOCK_UNLOCKED { {0}} 





还 有 : 


#define ARCH_SPIN_LOCK_UNLOCKED { ATOMIC_INIT(0) } 





这 是 对 于 [x86_64] 架构 ， 如 果 CONFIG_QUEVED_SPINLOCKS 内 核 配置 选项 语 用 的 情况 。 那 么 ， 
在 spin_lock_init 宏 的 扩展 之 后 ， 给 定 的 gen 将 会 初始 化 并 且 状 态 变 关 解锁 
(unlocked) ° 





从 这 一 时 刻 起 我 们 了 解 了 如 何 去 初 始 化 一 个 aki ， 现 在 考虑 Linux AKA BHM 的 操作 提 
供 的 APlo HA: 


static always inline void spin_lock(spinlock_t *lock) 


{ 


raw_spin_lock(&lock->rlock); 


此 函数 允许 我 们 RR 一 个 自 旋 锁 。 raw_spin_lock 宏 定义 在 同一 个 头 文 件 中 ， 并 且 扩 展 了 
_raw_spin_lock 函数 的 调用 : 


#define raw_spin_lock(lock) _raw_spin_lock(lock) 


就 像 在 include/linux/spinlock.h 头 文件 所 了 解 的 那样 ， _raw_spin_lock 宏 的 定义 依赖 于 
CONFIG_SMP 内 核 配置 参数 : 


#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK) 
# include <linux/spinlock_api_smp.h> 

#else 

# include <linux/spinlock_api_up.h> 

#endif 


因此 ， 如 果 在 Linux 内 核 中 SMP BAT > IRZ _raw_spin_lock 宏 就 在 
arch/x86/include/asm/spinlock.h 头 文件 中 定义 ， 并 且 看 起 来 像 这 样 : 


#define _raw_spin_lock(lock) __raw_spin_lock(lock) 


__raw_spin_lock žb 3l: 


static inline void __raw_spin_lock(raw_spinlock_t *lock) 

{ 
preempt_disable(); 
spin_acquire(&lock->dep_map, ©, ©, _RET_IP_); 
LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock); 


就 像 你 们 可 能 了 解 的 那样 ， 首先 我 们 禁用 了 抢占 ， 通 过 include/linux/preempt.h (在 Linux 内 
核 初始 化 进程 章节 的 第 九 部 分 会 了 解 到 更 多 关于 抢占 ) 中 的 preempt_disable 调用 实现 禁用 。 
当 我 们 将 要 解 开 给 定 的 see ， 抢 占 将 会 再 次 启用 : 


static inline void __raw_spin_unlock(raw_spinlock_t *lock) 


{ 


preempt_enable(); 


当 程 序 正在 自 旋 锁 时 ， 这 个 已 经 获取 锁 的 程序 必须 阻止 其 他 程序 方法 的 抢占 。 spin acquire 
宏 通 过 其 他 宏 宏 展 调用 实现 : 


#define spin_acquire(l, s, t, i) lock_acquire_exclusive(1l, s, t, NULL, 
i) 
#define lock_acquire_exclusive(l, s, t, n, i) lock_acquire(l, s, t, ©, 1, n, 
i) 


lock_acquire 函数 : 


void lock_acquire(struct lockdep_map *lock, unsigned int subclass, 
int trylock, int read, int check, 
struct lockdep_map *nest_lock, unsigned long ip) 


unsigned long flags; 


if (unlikely(current->lockdep_recursion) ) 
return, 


raw_local_irq_save(flags); 
check_flags(flags) ; 


current->lockdep_recursion = 1; 

trace_lock_acquire(lock, subclass, trylock, read, check, nest_lock, ip); 

__lock_acquire(lock, subclass, trylock, read, check, 
irqs_disabled_flags(flags), nest_lock, ip, 9, 0); 

current->lockdep_recursion = 0; 

raw_local_irgq_restore(flags); 


就 像 之 前 所 写 的 ， 我 们 不 考虑 这 些 调试 或 跟踪 相关 的 东西 。 lock_acquire 函数 的 主要 是 通过 
raw_local_irgq_save 宏 调 用 禁用 硬件 中 断 ， 因 为 给 定 的 自 旋 锁 可 能 被 启用 的 硬件 中 断 所 获 
取 。 以 这 样 的 方式 获取 的 话 程序 将 不 会 被 抢占 。 注 意 lock_acquire 函数 的 最 后 将 使 用 


raw_local_irq_restore esis 动 硬件 中 断 。 正 如 你 们 可 能 猜 到 的 那样 ， 主 要 工作 将 
在 _1lock_acquire BAP CL»? RS HARE kernel/locking/lockdep.c 源 代码 文件 中 。 


_lock_acquire 函数 看 起 来 很 大 。 我 们 将 试图 去 理解 这 个 函数 要 做 什么 ， 但 不 是 在 这 一 部 

分 。 事 实 上 这 个 函数 于 Linux 内 核 锁 验 证 器 (lock validator) aie ， nae 是 此 部 分 的 主 
题 。 如 果 我 们 要 返回 raw spin lock 函数 的 定义 ， 我 们 将 会 发 现 这 个 定义 包含 了 以 下 
的 定义 : 


LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock); 


LOCK_CONTENDED 宏 的 定义 在 include/linux/lockdep.h 头 文 件 中 ， 而 且 只 是 使 用 给 定 自 旋 锁 W 
用 已 知 有 函数 : 


#define LOCK_CONTENDED(_lock, try, lock) \ 
lock(_lock) 


在 本 例 中 ， lock 就 是 includellinux/spinlock.h 头 文件 中 的 do_raw spin lock ， 而 _lock 就 
是 给 定 的 raw_spinlock_t 


static inline void do_raw_spin_lock(raw_spinlock_t *lock) __acquires(lock) 


{ 
__acquire(lock); 
arch_spin_lock(&lock->raw_lock) ; 


这 里 的 acquire 只 是 [稀疏 (sparse)] 相 关 宏 ， 并 且 当 前 我 们 也 对 这 些 不 感 

趣 。 arch_spin lock 函数 定义 的 位 置 依赖 于 两 件 事 : 第 一 是 系统 架构 ， TP 
了 队列 自 旋 锁 (queued spinlocks) 。 本 例 中 我 们 仅 以 x86_64 架构 为 例 介 绍 ， 因 此 
arch_spin_lock 的 定义 的 宏 表 示 源 自 include/asm-generic/qspinlock.h 头 文件 中 : 


#define arch_spin_lock(1) queued_spin_lock(1) 


如 果 使 用 队列 自 族 锁 ， 或 者 其 他 例子 中 ， arch_spin_lock HAEA 
arch/x86/include/asm/spinlock.h 头 文 件 中 ， 如 何 处 理 ? 现 在 我 们 只 考虑 普通 的 自 旋 锁 ， 队列 自 
旋 锁 相关 的 信息 将 在 以 后 了 解 。 来 再 看 看 arch_spinlock 结构 的 定义 ， 理 解 以 下 
arch_spin_lock 有 函数 的 实现 : 


typedef struct arch_spinlock { 
union { 
__ticketpair_t head_tail; 
struct raw tickets { 
__ticket_t head, tail; 
} tickets; 
J; 
} arch_spinlock_t; 





这 个 自 旋 锁 的 变 体 被 称 为 标签 自 旋 锁 (ticket spinlock) ° 就 像 我 们 锁 了 解 的 ， an 
i 包括 两 个 部 分 。 当 锁 被 获取 ， 如 果 有 程序 想 要 获取 aki 它 就 会 将 尾部 (tail) 值 加 1 。 
RAR 不 等 于 sa ， 那 么 程序 就 会 被 锁 住 ， 直 到 这 些 变量 的 值 不 再 相等 。 来 看 

看 arch_spin_lock 函数 上 的 实现 : 


static _ always inline void arch_spin_lock(arch_spinlock_t *lock) 


{ 
register struct _ raw_tickets inc = { .tail = TICKET_LOCK_INC }; 


inc = xadd(&lock->tickets, inc); 


if (likely(inc.head == inc.tail)) 
goto out; 


for (77) { 
unsigned count 


SPIN_THRESHOLD,; 


do { 
inc.head = READ_ONCE(lock->tickets.head) ; 
if (__tickets_equal(inc.head, inc.tail)) 
goto clear_slowpath; 
cpu_relax(); 
} while (--count); 
ticket_lock_spinning(lock, inc.tail); 





} 
clear_slowpath: 
ticket_check_and_clear_slowpath(lock, inc.head); 





out: 
barrier(); 





arch_spin_lock 函数 在 一 开始 能 够 使 用 尾部 1 对 ”raw tickets 结构 初始 化 : 


#define TICKET_LOCK_INC 工 





在 inc 和 1lock->tickets 的 下 一 行 执行 xadd 操作 。 这 个 操作 之 后 inc 将 存储 给 定 标签 
(tickets) 的 值 ， 然 后 tickets.tail 将 增加 inc 或 1。 尾部 值 增加 1 意味 着 一 个 程序 
开始 尝试 持 有 锁 。 下 一 步 做 检查 ， 检 查 头 部 和 尾部 是 否 有 相同 的 值 。 如 果 值 相等 ， 这 意味 着 


没有 程序 持 有 锁 并 且 我 们 去 到 了 out 标签 。 在 arch_spin_lock 函数 的 最 后 ， 我 们 可 能 了 解 
J barrier KAA 屏障 指令 (barrier instruction) ， 该 指令 保证 了 编译 器 将 不 更 改进 入 内 存 
操作 的 顺序 (更 多 关于 内 存 屏 障 的 知识 可 以 阅读 内 核 文档 (documentation)) 。 


如 果 前 一 个 程序 持 有 锁 而 第 二 个 程序 开始 执行 arch_spin_lock HA BRA 头 部 将 不 会 等 于 
尾部 ， 因 为 尾部 比 头 部 大 1 。 这 样 ， 程 序 将 循环 发 生 。 在 每 次 循 坏 迭代 的 时 候 头 部 和 g 
部 的 值 进行 比较 。 如 果 值 不 相等 ，cpu_relax ， 也 就 是 NOP 指令 将 会 被 调用 : 


#define cpu_relax() asm volatile("rep; nop") 


后 将 开始 循环 的 下 一 次 迭代 。 如 果 值 相等 ， 这 意味 着 持 有 和 锁 的 程序 ， 释 放 这 个 锁 并 且 下 一 
个 程序 获取 这 个 锁 。 


spin_unlock 操作 遍 布 所 有 有 spin_lock 的 宏 或 函数 中 ， 当然 ， 使 用 的 是 unlock 前 Boo 最 
后 ， arch_spin_unlock 函数 将 会 被 调用 。 如 果 看 看 arch_spin_lock 函数 的 实现 ， 我 们 将 了 
解 到 这 个 函数 增加 了 lock tickets 列表 的 k% 


__add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); 


在 spin lock 和 spin_unlock 的 组 合 使 用 中 ， 我 们 得 到 一 个 队列 ， 其 xe 包含 了 一 个 索引 
号 ， 映 射 了 当前 执行 的 持 有 和 锁 的 程序 ， 而 尾部 包含 了 一 个 索引 号 ， 映 射 了 最 后 尝试 持 有 锁 的 
程序 : 


+------- + +------- + 
| | | | 
head | 7 |---| 7 | tail 
| | | | 
+------- + +------- + 
| 
+------- + 
| | 
| 8 | 
| | 
+------- + 
| 
+------- + 
| | 
| 9 | 
| | 
+------- + 
目前 这 就 是 全 部 。 这 一 部 分 不 涵盖 所 有 的 aka APl， 但 我 认为 这 个 概念 背后 的 主要 思想 现 
在 一 定 清楚 了 。 


涵盖 Linux 内 核 中 的 同步 原 语 的 第 一 部 分 到 此 结束 。 在 这 一 部 分 ， 我 们 遇见 了 第 一 个 Linux 内 
核 提 供 的 同步 原 语 ara 。 下 一 部 分 将 会 继续 深入 这 个 有 趣 的 主题 ， 而 且 将 会 了 解 到 其 他 同 
步 相关 的 知识 。 


如 果 您 有 疑问 或 者 建议 ， 请 在 twitter 0xAX 上 联系 我 ， 通 过 email 联系 我 ， 或 者 创建 一 个 
issue ° 


友情 提示 : 美语 不 是 我 的 母语 ， 对 于 译文 给 您 带 来 了 的 不 便 我 感到 非常 抱歉 。 如 果 您 发 现任 
何 错误 请 给 我 发 送 PR 到 linux-insides ° 
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这 是 本 章节 的 第 二 部 分 ， 这 部 分 描述 Linux 内 核 的 和 我 们 在 本 章 的 第 一 部 分 所 见 到 的 一 一 自 
旋 锁 的 同步 原 语 。 在 这 个 部 分 我 们 将 继续 学 习 自 旋 锁 的 同步 原 语 。 如 果 阅 读 了 上 一 部 分 的 相 
关内 容 ， 你 可 能 记得 除了 正常 自 旋 锁 ，Linux 内 核 还 提供 ARH 的 一 种 特殊 类 型 - 队列 自 旋 
Bo 在 这 个 部 分 我 们 将 尝试 理解 此 概念 锁 代 表 的 含义 。 


我 们 在 上 一 部 分 已 知 自 旋 锁 的 API: 


© spin_lock_init -为 给 定 自 旋 锁 进行 初始 化 ; 

e spin_lock - 获取 给 定 自 旋 锁 ; 

e spin_lock_bh - 禁止 软件 中 断 并 且 获 取 给 定 自 旋 锁 ; 

@ spin_lock_irqsave 和 spin_lock_irq - 禁止 本 地 处 理 器 中 断 并 且 保 存 /不 保存 之 前 标识 
位 的 中 断 状态 ; 

e spin_unlock -释放 给 定 的 自 旋 锁 3 

e spin_unlock_bh - 释放 给 定 的 aza 并 且 司 用 软件 中 断 ; 

e spin_is_locked -返回 给 定 自 旋 锁 的 状态 ; 


KE KE 


而 且 我 们 知道 所 有 这 些 宏 都 在 include/linux/spiniock.h 头 文件 中 所 定义 ， 都 被 扩展 成 针对 
x86_64 架构 ， 来 自 于 arch/x86/include/asm/spinlock.h 文件 的 arch_spin_.* 前 级 的 函数 调 
用 。 如 果 我 们 关注 这 个 头 文件 ， 我 们 会 发 现 这 些 函 数 ( arch_spin_is_locked ， 
arch_spin_lock ， arch_spin_unlock 等 等 ) 只 在 CONFIG_QUEUED_SPINLOCKS 内 核 配 置 选 项 禁 


用 的 时 才 定 义 : 


#ifdef CONFIG_QUEUED_SPINLOCKS 

#include <asm/qspinlock.h> 

#else 

static always inline void arch_spin_lock(arch_spinlock_t *lock) 


{ 


#endif 


这 意味 着 arch/x86/include/asm/qspinlock.h 这 个 头 文件 提供 提供 这 些 函 数 自己 的 实现 。 实 际 
上 这 些 函 数 是 宏 定 义 并 且 在 分 布 在 其 他 头 文件 中 。 这 个 头 文件 是 include/asm- 
generic/qspinlock.h。 如 果 我 们 查看 这 个 头 文件 ， 我 们 会 发 现 这 些 宏 的 定义 : 


#define arch_spin_is_locked(1) queued_spin_is_locked(1) 
#define arch_spin_is_contended(1) queued_spin_is_contended(1) 
#define arch_spin_value_unlocked(1) queued_spin_value_unlocked(1) 
#define arch_spin_lock(1) queued_spin_lock(1) 

#define arch_spin_trylock(1) queued_spin_trylock(1l) 
#define arch_spin_unlock(1) queued_spin_unlock(1) 

#define arch_spin_lock_flags(1, f) queued_spin_lock(1) 

#define arch_spin_unlock_wait(1) queued_spin_unlock_wait(1l) 


在 我 们 考虑 怎么 排列 自 旋 锁 和 实现 他 们 的 API， 我 们 首先 看 看 理论 部 分 。 


介绍 队列 目 旋 锁 


队列 自 旋 锁 是 Linux 内 核 的 锁 机 制 ， 是 标准 自 旋 锁 的 代替 物 。 至 少 对 x86 64 RIEA o ka 
果 我 们 查看 了 以 下 内 核 配 置 文件 - kernel/Kconfig.locks， 我 们 将 会 发 现 以 下 配置 入 口 : 


config ARCH_USE_QUEUED_SPINLOCKS 
bool 


config QUEUED_SPINLOCKS 
def_bool y if ARCH_USE_QUEUED_SPINLOCKS 
depends on SMP 


这 意味 着 如 果 ARCH_USE_QUEUED_SPINLOCKS Æ M] > ARZ CONFIG QUEUED_SPINLOCKS WA 4% BC A $ 
项 将 默认 启用 。 我们 能 够 看 到 ARCH_USE QUEUED_SPINLOCKS 在 x86 64 特定 内 核 配置 文件 - 
arch/x86/Kconfig 默认 开启 : 


config X86 


select ARCH_USE_QUEUED_SPINLOCKS 


在 开始 考虑 什么 是 队列 自 旋 锁 概 念 之 前 ， 让 我 们 看 看 其 他 自 旋 锁 的 类 型 。 一 开始 我 们 考虑 E 
常 自 旋 锁 是 如 何 实现 的 。 通 常 ， 正 常 自 旋 锁 的 实现 是 基于 test and set 指令 。 这 个 指令 的 工 
作 原 则 站 的 很 简单 。 该 指令 写 入 一 个 值 到 内 存 地 址 然后 返回 该 地 址 原来 的 日 值 。 这 些 操作 都 


是 在 院子 的 上 下 文中 完成 的 。 也 就 是 说 ， 这 个 指令 是 不 可 中 断 的 。 因 此 如 果 第 一 个 线程 开始 
执行 这 个 指令 ， 第 二 个 线程 将 会 等 待 ， 直 到 第 一 个 线程 完成 。 基 本 锁 可 以 在 这 个 机 制 之 上 建 
立 。 可 能 看 起 来 如 下 所 示 : 


int lock(lock) 


{ 
while (test_and_set(lock) == 1) 
return 0: 
} 
int unlock(lock) 
{ 
lock=0; 
return lock; 
} 


第 一 个 线程 将 执行 test_and_set 指令 设置 lock A 1 ° 当 第 二 个 线程 调用 lock hak? 
它 将 在 while 循环 中 自 旋 ， 直到 第 一 个 线程 调用 unlock HA mE lock 等 于 6。 这 个 实 
现 对 于 执行 不 是 很 好 ， 因 为 该 实现 至 少 有 两 个 问题 。 第 一 个 问题 是 该 实现 可 能 是 非 公平 的 而 
且 一 个 处 理 器 的 线程 可 能 有 很 长 的 等 待 时 间 ， 即 使 有 其 他 线程 也 在 等 待 释 放 锁 ， 它 还 是 调用 
了 lock 。 第 二 个 问题 是 所 有 想 要 获取 锁 的 线程 ， 必 须 在 共享 内 存 的 变量 上 执行 很 多 类 

似 test_and_set 这 样 的 原子 操作 。 这 导致 缓存 失效 ， 因 为 处 理 器 缓存 会 存储 lock=1 ， 但 是 
在 线程 释放 锁 之 后 ， 内 存 中 lock 可 能 只 是 1。 


在 上 一 部 分 我 们 了 解 了 自 旋 锁 的 第 二 种 实现 - HM ARH (ticket spinlock) 。 这 一 方法 解决 了 
第 一 个 问题 而 且 能 够 保证 想 要 获取 锁 的 线程 的 顺序 ， 但 是 仍然 存在 第 二 个 问题 。 


这 一 部 分 的 主旨 是 队列 自 旋 令 。 这 个 方法 能 够 帮助 解决 上 述 的 两 个 问题 。 队列 自 旋 领 允许 每 个 
处 理 器 对 自 旋 过 程 使 用 他 自己 的 内 存 地 址 。 通 过 学 习 名 为 MCS 锁 的 这 种 基于 队列 自 旋 锁 的 实 
现 ， 能 够 最 好 理解 基于 队列 自 旋 锁 的 基本 原则 。 在 了 解 队列 自 旋 锁 的 实现 之 前 ， 我 们 先 尝试 理 
解 什么 是 mcs 锁 。 


mcs 锁 的 基本 理念 就 在 上 一 段 已 经 写 到 了 ， 一 个 线程 在 本 地 变量 上 自 旋 然后 每 个 系统 的 处 理 
器 自己 拥有 这 些 变量 的 拷贝 。 换 名 话说 这 个 概念 建立 在 Linux 内 核 中 的 per-cpu 变量 概念 之 
上 。 


当 第 一 个 线程 想 要 获取 锁 ， 线 程 在 队列 中 注册 了 自身 ， 或 者 换 句 话说 ， 因 为 线程 现在 是 闲置 
的 ， 线 程 要 加 入 特殊 以 列 并 且 获 取 锁 。 当 第 二 个 线程 想 要 在 第 一 个 线程 释放 锁 之 前 获取 相同 
锁 ， 这 个 线程 就 会 把 他 自身 的 所 变量 的 拷贝 加 入 到 这 个 特殊 队列 中 。 这 个 例子 中 第 一 个 线程 
会 包含 一 个 next 字段 指向 第 二 个 线程 。 从 这 一 时 刻 ， 第 二 个 线程 会 等 待 直到 第 一 个 线程 释 
放 它 的 锁 并 且 关 于 这 个 事件 通知 给 next 线程 。 第 一 个 线程 从 队列 中 删除 而 第 二 个 线程 持 有 
该 锁 。 


我 们 可 以 这 样 代 表示 意 一 下 : 
空 队列 

he + 

| | 

| Queue | 

l | 

eee ac + 


| | 
| Queue |---->| 
| | 


| Queue |---->| 
ck | 


或 者 伪 代 码 描述 为 : 


First thread acquired lock | 


Second thread waits for first thread 


|<----| First thread holds lo 


vordi locka) 





{ 
lock.next = NULL; 
ancestor = put_lock_to_queue_and_return_ancestor(queue, lock); 
// if we have ancestor, the lock already acquired and we 
// need to wait until it will be released 
if (ancestor) 
{ 
lock.locked = 1; 
ancestor.next = lock; 
while (lock.is_locked == true) 
} 
// in other way we are owner of the lock and may exit 
} 
void unlock(...) 
{ 
// do we need to notify somebody or we are alonw in the 
// queue? 
if (lock.next != NULL) { 
// the while loop from the lock() function will be 
// finished 
lock.next.is_locked = false; 
// delete ourself from the queue and exit 
ne 
} 
// So, we have no next threads in the queue to notify about 
// lock releasing event. Let's just put ~0 to the lock, will 
// delete ourself from the queue and exit. 
} 


想法 很 简单 ， 但 是 以 列 自 旋 锁 的 实现 一 定 是 比 伪 代 码 复 杂 。 就 如 同 我 上 面 写 到 的 ， 队列 自 旋 

锁 机 制 计划 在 Linux 内 核 中 成 为 排队 自 族 领 的 替代 品 。 但 你 们 可 能 还 记得 ， 常 用 自 族 锁 适用 
于 32 位 (32-bit) 的 字 (Word)。 而 基于 mes 的 锁 不 能 使 用 这 个 大 小 ， 你 们 可 能 知道 

spinlock_t 类 型 在 Linux 内 核 中 的 使 用 是 宽 字 符 (widely) 的 。 这 种 情况 下 可 能 不 得 不 重 写 
Linux 内 核 中 重要 的 组 成 部 分 ， 但 这 是 不 可 接受 的 。 除 了 这 一 点 ， 一 些 包 含 自 旋 锁 用 于 保护 的 
内 核 结 构 不 能 增长 大 小 。 但 无 论 怎样 ， 基 于 这 一 概念 的 Linux 内 核 中 的 队列 自 旋 锁 实现 有 一 些 
修改 ， 可 以 适应 32 位 的 字 。 


这 就 是 所 有 有 关 wage 的 理论 ， 现 在 让 我 们 考虑 以 下 在 Linux 内 核 中 这 个 机 制 是 如 何 实现 
的 。 MAARA 的 实现 看 起 来 比 排队 自 旋 锁 的 实现 更 加 复杂 和 混乱 ， 但 是 细致 的 研究 会 引导 成 
功 。 


队列 自 旋 锁 的 API 


现在 我 们 从 原理 角度 了 解 了 一 些 paara ， 是 时 候 了 解 Linux 内 核 中 这 一 机 制 的 实现 了 。 就 
像 我 们 之 前 了 解 的 那样 include/asm-generic/qspinlock.h 头 文 件 提供 一 套 宏 ， 代 表 API 中 的 
自 旋 销 的 获取 、 释 放 等 等 。 


#define arch_spin_is_locked(1) queued_spin_is_locked(1) 
#define arch_spin_is_contended(1) queued_spin_is_contended(1) 
#define arch_spin_value_unlocked(1) queued_spin_value_unlocked(1) 
#define arch_spin_lock(1) queued_spin_lock(1) 

#define arch_spin_trylock(1) queued_spin_trylock(1) 
#define arch_spin_unlock(1) queued_spin_unlock(1) 

#define arch_spin_lock_flags(1, f) queued_spin_lock(1) 

#define arch_spin_unlock_wait(1) queued_spin_unlock_wait(1l) 


所 有 这 些 宏 扩展 了 同一 头 文件 下 的 函数 的 调用 。 此 外 ， 我 们 发 现 include/asm- 
generic/qspinlock types.h 头 文 件 的 qspinlock 结构 代表 了 Linux 内 核 队 列 自 旋 锁 。 


typedef struct qspinlock { 
atomic_t val; 
} arch_spinlock_t; 


如 我 们 所 了 解 的 ， qspinlock 结构 只 包含 了 一 个 字段 - val 。 这 个 字段 代表 给 定 hra HR 
态 。 4 个 字 节 字 段 包 括 如 下 4 个 部 分 : 


e 9-7 - 上 锁 字 节 (locked byte); 

e 8 -未 决 位 (pending bit); 

e 16-17 - 这 两 位 代表 了 mcs 人 锁 的 per_cpu 数组 (马上 就 会 了 解 ) ; 
© 18-31 - 包括 表明 队列 尾部 的 处 理 器 数 。 


9-15 字 节 没有 被 使 用 。 
就 像 我 们 已 经 知道 的 ， 系 统 中 每 个 处 理 器 有 自己 的 锁 找 贝 。 这 个 锁 由 以 下 结构 所 表示 : 


struct mcs_spinlock { 
struct mcs_spinlock *next; 
int locked; 
int count; 


来 自 kernel/locking/mcs_spinlock.h 头 文件 。 第 一 个 字段 代表 了 指向 队列 中 下 一 个 线程 的 指 

针 。 第 二 个 字段 代表 了 na 中 当前 线程 的 状态 ， 其 中 1 是 a 已 经 获取 而 6 相反 。 然 后 

最 后 一 个 mcs_spinlock 字段 结构 代表 嵌 套 锁 (nested locks) > T AAA CHK ABA > RARR 
一 下 当 线程 已 经 获取 倘 的 情况 ， 而 被 硬件 中 断 所 中 断 ， 然 后 中 断 处 理 程序 又 尝试 获取 锁 。 这 
个 例子 里 ， 每 个 处 理 器 不 只 是 mcs_spinlock 结构 的 拷贝 ， 也 是 这 些 结 构 的 数组 : 


static DEFINE_PER_CPU_ALIGNED(struct mcs_spinlock, mcs_nodes[4]); 


此 数组 允许 以 下 情况 的 四 个 事件 的 锁 获 取 的 四 个 尝试 (原文 : This array allows to make four 
attempts of a lock acquisition for the four events in following contexts: ) : 


o 普通 任务 上 下 文 ; 
e 硬件 中 断 上 下 文 ; 
e 软件 中 断 上 下 文 ; 
。 屏蔽 中 断 上 下 文 


o 


现在 让 我 们 返回 qspinlock 结构 和 队列 自 旋 锁 的 apr 中 来 。 在 我 们 考虑 队列 自 族 锁 的 API 
之 前 ， 请 注意 qspinlock 结构 的 val 字段 有 类 型 - atomict ， 此 类 型 代表 原子 变量 或 者 变 
量 的 一 次 操作 (原文 : one operation at a time variable)。 一 次 ， 所 有 这 个 字段 的 操作 都 是 原子 
的 。 比 如 说 让 我 们 看 看 val API 的 值 : 


static __always_inline int queued_spin_is_locked(struct qspinlock *lock) 


{ 


return atomic_read(&lock->val); 


} 


Ok， 现 在 我 们 知道 Linux 内 核 的 代表 队列 自 旋 锁 数据 结构 ， 那 么 是 时 候 看 看 队列 自 旋 锁 API 
中 主要 (main) BRA KM o 


#define arch_spin_lock(1) queued_spin_lock(1) 
没 错 ， 这 个 nas queued_spin_lock ° 正如 我 们 可 能 从 有 函数 名 中 所 了 解 的 一 样 > HA AT 


通过 线程 获取 锁 。 这 个 函数 在 include/asm-generic/qspinlock types.h 头 文件 中 定义 ， 它 的 实 
纲 看 起 来 是 这 样 : 


ss 


SA 


static __always_inline void queued_spin_lock(struct qspinlock *lock) 


{ 
U32 val; 


val = atomic_cmpxchg_acquire(&lock->val, ©, _Q_ LOCKED_VAL); 
if (likely(val == 0)) 

return; 
queued_spin_lock_slowpath(lock, val); 


看 起 来 很 简单 ， 除 了 queued_spin_lock_slowpath 函数 ， 我 们 可 能 发 现 它 只 有 一 个 参数 。 在 我 
们 的 例子 中 这 个 参数 代表 队列 自 旋 领 被 上 锁 。 让 我 们 考虑 队列 锁 为 室 ， 现 在 第 一 个 线程 想 要 
获取 锁 的 情况 正如 我 们 可 能 了 解 的 queued_spin_lock 函数 从 调用 atomic_cmpxchg_acquire 
宏 开始 。 pean ees 的 名 字 猜 到 的 那样 ， 它 执行 原子 的 CMPXCHG 484 > 18 BA 
参数 (当前 给 定 自 旋 锁 的 状态 ) 比较 第 二 个 参数 (在 我 们 的 例子 为 零 ) 的 值 ， 如果 他 们 相 
等 ， 那 么 persai 存储 位 置 保存 Q Locken VAL 的 值 ， 该 存储 位 置 通过 &lock->val 指 
向 并 且 返 回 这 个 存储 位 置 的 初始 值 。 


atomic_cmpxchg_acquire 定义 在 include/linux/atomic.h 头 文 件 中 并 且 扩 展 了 
atomic_cmpxchg ep， : 


#define atomic_cmpxchg_acquire atomic_cmpxchg 


这 实现 是 架构 所 指定 的 。 我 们 考虑 x86_64 架构 ， 因 此 在 我 们 的 例子 中 这 个 头 文件 在 
arch/x86/include/asm/atomic.h 并 且 atomic_cmpxchg ak) FILA LIKE cmpxchg BA 


果 : 


static _ always_inline int atomic_cmpxchg(atomic_t *v, int old, int new) 


{ 


return cmpxchg(&v->counter, old, new); 


这 个 宏 在 arch/x86/include/asm/cmpxchg.h 头 文件 中 定义 ， 看 上 去 是 这 样 


#define cmpxchg(ptr, old, new) \ 
__cmpxchg(ptr, old, new, sizeof(*(ptr))) 


#define __cmpxchg(ptr, old, new, size) \ 
__raw_cmpxchg((ptr), (old), (new), (size), LOCK_PREFIX) 


就 像 我 们 可 能 了 解 的 那样 ， cmpxchg 宏 使 用 几乎 相同 的 参数 集合 扩展 了 _cpmxchg 宏 。 新 添 
加 的 参数 是 原子 值 的 大 小 。 _cpmxchg 宏 添 加 了 Lock_PREFIX ， 还 扩展 了 _raw cmpxchg & 
中 Lock PREFIX 的 LOCK 指 令 。 毕 竞 raw cmpxchg 对 我 们 来 说 做 了 所 有 的 的 工作 : 


#define __raw_cmpxchg(ptr, old, new, size, lock) \ 


({ 
volatile u32 *_ ptr = (volatile u32 *)(ptr); \ 
asm volatile(lock "cmpxchgl %2,%1" \ 
=a (et) arme EN) \ 
> "r' (__new), "" (__old) \ 
: "memory"); \ 

}) 


在 atomic_cmpxchg_acquire 宏 被 执行 后 ， 该 宏 返 回 内 存 地 址 之 前 的 值 。 现 在 只 有 一 个 线程 尝 
试 获取 锁 ， 因 此 val 将 会 置 为 零 然 后 我 们 从 queued_spin_lock 函数 返回 : 


val = atomic_cmpxchg_acquire(&lock->val, ©, _Q_LOCKED_VAL); 
if (likely(val == 0)) 
return, 


此 时 此 刻 ， 我 们 的 第 一 个 线程 持 有 锁 。 注 意 这 个 行为 与 在 wes 算法 的 描述 有 所 区 别 。 线 程 获 
取 锁 ， 但 是 我 们 不 添加 此 线程 入 队列 。 就 像 我 之 前 已 经 写 到 的 ， 队列 自 族 锁 概念 的 实现 在 
Linux 内 核 中 基于 ms 算法 ， 但 是 于 此 同时 它 对 优化 目的 有 一 些 差异 。 


所 以 第 一 个 线程 已 经 获取 了 锁 然 后 现在 让 我 们 考虑 第 二 个 线程 尝试 获取 相同 的 锁 的 情况 。 第 
二 个 线程 将 从 同样 的 queued_spin_lock 函数 开始 ， 但 是 lock->val 会 包含 1 或 者 
Q LOCKED_VAL ， 因 为 第 一 个 线程 已 经 持 有 了 和 锁 。 因 此 ， 在 本 例 中 
queued_spin_lock_slowpath 函数 将 会 被 调用 。 queued_spin_lock_slowpath 函数 定义 在 
kernel/locking/qspinlock.c 源码 文件 中 并 且 从 以 下 的 检查 开始 : 


void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val) 
{ 
if (pv_enabled()) 
goto queue; 


if (virt_spin_lock(lock)) 
return; 


这 些 检 查 操 作 检 查 了 pvqspinlock 的 状态 。 pvqspinlock 是 在 准 虚 拟 化 (paravirtualized ) 
环境 中 的 队列 自 族 锁 。 就 像 这 一 章节 只 相关 Linux 内 核 同步 原 语 一 样 ， 我 们 跳 过 这 些 和 其 他 不 
直接 相关 本 章节 主题 的 部 分 。 这 些 检查 之 后 我 们 比较 使 用 _Q_PENDING_VAL 宏 的 值 所 代表 的 
锁 ， 然 后 什么 都 不 做 直到 该 比较 为 上 (原文 : After these checks we compare our value 
which represents lock with the value of the _Q PENDING VAL macro and do nothing while this 
is true ) 


if (val == _Q PENDING_VAL) { 
while ((val = atomic_read(&lock->val)) == _Q PENDING_VAL) 


cpu_relax(); 


这 里 cpu relax RÆ NOP 指令 。 综 上 ， 我 们 了 解 了 锁 人 饱含 着 - pending 位 。 这 个 位 代表 了 
想 要 获取 锁 的 线程 ， 但 是 这 个 锁 已 经 被 其 他 线程 获取 了 ， 并 且 与 此 同时 队列 AZo EAS 
P > pending 位 将 被 设置 并 且 队列 不 会 被 创建 (touched)。 这 是 优化 所 完成 的 ， 因 为 不 需要 
考虑 在 引发 缓存 无 效 的 自身 mcs_spinlock 数组 的 创建 产生 的 非 必 需 隐患 (原文 This is 
done for optimization, because there are no need in unnecessary latency which will be 
caused by the cache invalidation in a touching of own mcs_spinlock array.) 。 


下 一 步 我 们 进入 下 面 的 循环 : 


for (77) { 
if (val & ~_Q_LOCKED_MASK) 
goto queue; 


new = _Q _LOCKED_VAL; 
if (val == new) 
new |= _Q PENDING_VAL; 


old = atomic_cmpxchg_acquire(&lock->val, val, new); 
if (old == val) 
break; 


val = old; 


这 里 第 一 个 if PIREN ( val ) 的 状态 是 上 锁 还 是 待定 的 (pending)。 这 意味 着 第 一 个 线 
程 已 经 获取 了 锁 ， 第 二 个 线程 也 试图 获取 锁 ， 但 现在 第 二 个 线程 是 待定 状态 。 本 例 中 我 们 需 
要 开始 建立 队列 。 我 们 将 稍 后 考虑 这 个 情况 。 在 我 们 的 例子 中 ， 第 一 个 线程 持 有 锁 而 第 二 个 
线程 也 尝试 获取 锁 。 这 个 检查 之 后 我 们 在 上 锁 状 态 并 且 使 用 之 前 锁 状 态 比 较 后 创建 新 锁 。 就 
像 你 记得 的 那样 ，val 包含 了 &lock->val 状态 ， 在 第 二 个 线程 调用 

atomic_cmpxchg_acquire 宏 后 状态 将 会 等 于 1 ° HF new 和 val 的 值 相等 ， 所 以 我 们 在 
第 二 个 线程 的 锁 上 设置 待定 位 。 在 此 之 后 ， 我 们 需要 再 次 检查 &lock->val Hi 因为 第 一 
个 线程 可 能 在 这 个 时 候 释 放 锁 。 如 果 第 一 个 线程 还 又 没 释放 锁 ， 虽 的 值 将 等 于 val (AA 


atomic_cmpxchg_acquire 将 会 返回 存储 地 址 指向 lock->val 的 值 并 且 当 前 为 1) 然后 我 们 
将 退出 循环 。 因 为 我 们 退出 了 循环 ， 我 们 会 等 待 第 一 个 线程 直到 它 释 放 锁 ， 清 除 待定 位 ， 获 
取 锁 并 且 返 回 


smp_cond_acquire(!(atomic_read(&lock->val) & _Q LOCKED_MASK)); 
clear_pending_set_locked(lock); 
return; 


注意 我 们 还 没 创建 队列。 这 里 我 们 不 需要 ， 因 为 对 于 两 个 线程 来 说 ， 队 列 只 是 导致 对 内 存 访 
问 的 非 必 需 潜在 因素 。 在 其 他 的 例子 中 ， 第 一 个 线程 可 能 在 这 个 时 候 释 放 其 锁 。 在 本 例 中 
lock->val 将 包含 Q@ LOCKED VAL | _Q_PENDING_VAL 并 且 我 们 会 开始 建立 队列 。 通 过 获得 处 
理 器 执行 线程 的 本 地 mcs_nodes 数组 的 拷贝 我 们 开始 建立 队列 





node = this_cpu_ptr(&mcs_nodes[0]); 
idx = node->count++; 
tail = encode_tail(smp_processor_id(), idx); 


除 此 之 外 我 们 计算 表示 队列 尾部 和 代表 mcs_nodes 数组 实体 的 索引 的 tail 。 在 此 之 后 我 
们 设置 node 指向 正确 的 mcs_nodes 数组 ， 设 置 locked 为 零 应 为 这 个 线程 还 没有 获取 锁 ， 
还 有 next A NULL 因为 我 们 不 知道 任何 有 关 其 他 队列 实体 的 信息 : 


node += idx; 
node->locked = 0; 
node->next = NULL; 


我 们 已 经 创建 了 对 于 执行 当前 线程 想 获 取 锁 Lagi 队列 的 每 个 cpu (per-cpu) ”的 拷贝 
这 意味 着 锁 的 拥有 者 可 能 在 这 个 时 刻 释放 了 锁 。 因 此 我 们 可 能 通 queued_spin_trylock % 
数 的 调用 尝试 去 再 次 获取 锁 。 


if (queued_ spin_trylock(lock)) 
goto release; 


queued_spin_trylock 4&7 include/asm-generic/qspinlock.h 头 文件 中 被 定义 而 且 就 像 
queued_spin_lock 函数 一 样 : 


static always_inline int queued_spin_trylock(struct qspinlock *lock) 
{ 
if (!atomic_read(&lock->val) && 
(atomic_cmpxchg_acquire(&lock->val, ©, _Q_LOCKED_VAL) == 0)) 
return T 
return 0; 


如 果 锁 成 功 被 获取 那么 我 们 跳 过 释放 标签 而 释放 队列 中 的 一 个 节点 : 


release: 


this_cpu_dec(mcs_nodes[@].count); 


现在 我 们 不 再 需要 它 了 ， 因 为 锁 已 经 获得 了 。 如 果 queued_spin_trylock 不 成 功 ， 我 们 更 新 
队列 的 尾部 : 


old = xchg_tail(lock, tail); 
然后 检索 原先 的 尾部 。 下 一 步 是 检查 队列 是 否 为 室 。 这 个 例子 中 我 们 需要 用 新 的 实体 链接 之 
前 的 实体 : 


if (old & _Q TAIL_MASK) { 
prev = decode_tail(old); 
WRITE_ONCE(prev->next, node); 


arch_mcs_spin_lock_contended(&node->locked) ; 





队列 实体 链接 之 后 ， 我 们 开始 等 待 直到 队列 的 头 部 到 来 。 由 于 我 们 等 待 头 部 ， 我 们 需要 对 可 
能 在 这 个 等 待 实践 加 入 的 新 的 节点 做 一 些 检查 : 


next = READ ONCE(node->next); 
if (next) 
prefetchw(next); 


如 果 新 节点 被 添加 ， 我 们 从 通过 使 用 PREFETCHW 指令 指出 下 一 个 队列 实体 的 内 存 中 预先 去 
除 缓存 线 (cache line) 。 以 优化 为 目的 我 们 现在 预先 载 入 这 个 指针 。 我 们 只 是 改变 了 队列 的 
头 而 这 意味 着 有 将 要 到 来 的 mes 进行 解锁 操作 并 且 下 一 个 实体 会 被 创建 。 


是 的 ， 从 这 个 时 刻 我 们 在 队列 的 头 部 。 但 是 在 我 们 有 能 力 获 取 锁 之 前 ， 我 们 需要 至 少 等 待 两 
个 事件 : 当前 锁 的 拥有 者 释放 锁 和 第 二 个 线程 处 于 待定 位 也 获取 锁 : 


smp_cond_acquire(!((val = atomic_read(&lock->val)) & Q LOCKED PENDING MASK)); 
两 个 线程 都 释放 锁 后 ， 以 列 的 头 部 会 持 有 人 锁 。 最 后 我 们 只 是 需要 更 新 队列 尾部 然后 移 除 从 队 
列 中 移 除 头 部 。 


以 上 。 


总 结 


Eck 
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这 是 Linux 内 核 同步 原 语 章节 第 二 部 分 的 结尾 。 在 上 一 个 部 分 我 们 已 经 见 到 了 第 一 个 同步 原 
语 Axe 通过 Linux AK 实现 排队 自 旋 锁 (ticket spinlock) 。 在 这 个 部 分 我 们 了 解 了 另 一 
个 BRM 机 制 的 实现 - 队列 自 旋 锁 。 下 一 个 部 分 我 们 继续 深入 Linux 内 核 同步 原 语 。 


如 果 您 有 疑问 或 者 建议 ， 请 在 twitter OxAX 上 联系 我 ， 通 过 email 联系 我 ， 或 者 创建 一 个 
issue. 


友情 提示 : 美语 不 是 我 的 母语 ， 对 于 译文 给 您 带 来 了 的 不 便 我 感到 非常 抱歉 。 如 果 您 发 现任 
何 错误 请 给 我 发 送 PR 到 linux-insides。 


链接 


èe Spinlock 
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e CMPXCHG instruction 
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e PREFETCHW instruction 
e x86_64 

e Previous part 


这 是 本 章 的 第 三 部 分 chapter， 本 章 描述 了 内 核 中 的 同步 原 语 ,在 之 前 的 部 分 我 们 见 到 了 特殊 的 
自 旋 锁 - 排队 自 旋 锁 。 在 更 前 的 部 分 是 和 wee 相关 的 描述 。 我 们 将 描述 更 多 同步 原 语 。 
在 ARH 之 后 的 下 一 个 我 们 将 要 讲 到 的 内 核 同 步 原 语 是 信号 量 。 我 们 会 从 理论 角度 开始 学 


习 什 么 是 信号 量 ， 然后 我 们 会 像 前 几 章 一 样 讲 到 Linux 内 核 是 如 何 实现 信号 量 的 。 


好 吧 ， 现 在 我 们 开始 。 


介绍 Linux 内 核 中 的 信号 量 


那么 究竟 什么 是 信号 量 ?就 像 你 可 以 猜 到 那样 - 信号 量 是 另外 一 种 支持 线程 或 者 进程 的 同 
步 机 制 。Linux 内 核 已 经 提供 了 一 种 同步 机 制 - axe ， 为 什么 我 们 还 需要 另外 一 种 呢 ?为 了 
回答 这 个 问题 ， 我 们 需要 理解 这 两 种 机 制 。 我 们 已 经 熟悉 了 sem ,因此 我 们 从 信号 量 机 制 
开始 。 


自 族 锁 的 设计 理念 是 它 仅 会 被 持 有 非常 短 的 时 间 。 但 持 有 自 旋 锁 的 时 候 我 们 不 可 以 进入 睡眠 
模式 因为 其 他 的 进程 在 等 待 我 们 。 为 了 防止 死 锁 上 下 文 交换 也 是 不 允许 的 。 


当 需 要 长 时 间 持 有 一 个 锁 的 时 候 信号 量 就 是 一 个 很 好 的 解决 方案 。 从 另 一 个 方面 看 ， 这 个 机 
制 对 于 需要 短期 持 有 锁 的 应 用 并 不 是 最 优 。 为 了 理解 这 个 问题 ， 我 们 需要 知道 什么 是 信号 


量 o 


就 像 一 般 的 同步 原 语 ， 信号 量 是 基于 变量 的 。 这 个 变量 可 以 变 大 或 者 减少 ， 并 且 这 个 变量 的 
状态 代表 了 获取 锁 的 能 力 。 注 意 这 个 变量 的 值 并 不 限于 o 和 1 。 有 两 种 类 型 的 信号 量 : 


ag 


第 一 种 信号 量 的 值 可 以 为 1 或 者 6。 第 二 种 信号 量 的 值 可 以 为 任何 非 负数 。 如 果 信号 
量 的 值 大 于 1 那么 它 被 叫做 计数 信号 量 ， 并 且 它 允许 多 于 1 个 进程 获取 它 。 这 种 机 制 允 
许 我 们 记录 现 有 的 资源 ， 而 自 旋 锁 只 允许 我 们 为 一 个 任务 上 锁 。 除 了 所 有 这 些 之 外 ， 另 外 一 
个 重要 的 点 是 BFE 允许 进入 睡眠 状态 。 另外 当 某 进程 在 等 待 一 个 被 其 他 进程 获取 的 锁 

时 ， 调度 器 也 许 会 切换 别 的 进程 。 


` 


信号 量 API 


因此 ， 我 们 从 理论 方面 了 解 一 些 信号 量 的 知识 ， 我 们 来 看 看 它 在 Linux 内 核 中 是 如 何 实现 的 。 
所 有 信号 量 相关 的 API 都 在 名 为 include/linux/semaphore.h 的 头 文 件 中 


我 们 看 到 信号 量 机 制 是 有 以 下 的 结构 体 表示 的 : 


struct semaphore { 


raw_spinlock_t lock; 
unsigned int count; 
struct list_head wait_list; 


}; 


在 内 核 中 ， 信号 量 结构 体 由 三 部 分 组 成 : 


e lock -保护 信号 量 的 自 旋 锁 ， 
© count - 现 有 资源 的 数量 ; 
e wait _ list -等 待 获取 此 锁 的 进程 序列 . 


在 我 们 考虑 Linux 内 核 的 的 信号 量 AP| 之 前 ， Shia a 信号 量 。 事 实 


上 ，Linux 内 核 提 供 了 两 个 信号 量 的 初始 函数 。 这 些 函 数 允 许 初始 化 一 个 信号 量 A: 
e #A: 
@ 动态 


我 们 来 看 看 第 一 个 种 初始 化 静态 信号 量 。 我 们 可 以 使 用 DEFINE_SEMAPHORE 宏 将 信号 量 静态 
初始 化 。 


#define DEFINE_SEMAPHORE(name) \ 
struct semaphore name = __SEMAPHORE_INITIALIZER(name, 1) 


就 像 我 们 看 到 这 样 ， DEFINE_SEMAPHORE 宏 只 提供 了 初始 化 = 值 信号 量 。 DEFINE SEMAPHORE 
宏 展 开 到 信号 量 结构 体 的 定义 。 结 构 体 通 过 ”SEMAPHORE_INITIALIZER 宏 初 始 化 。 我 们 来 看 
看 这 个 宏 的 实现 





#define __SEMAPHORE_INITIALIZER(name, n) \ 

{ \ 
.lock = RAW_SPIN_LOCK_UNLOCKED( (name) .lock), \ 
count =n, N 
.wait_list = LIST_HEAD_INIT((name).wait_list), \ 


__SEMAPHORE_INITIALIZER 宏 传 入 了 信号 量 =n 体 的 名 字 并 且 初 始 化 这 个 结构 体 的 各 个 域 。 
首先 我 们 使 用 ”RAW_SPIN_LOCK_UNLOCKED 宏 对 给 予 的 信号 量 初始 化 一 个 HM 。 就 像 你 从 
之 前 的 部 分 看 到 那样 ， RAW_SPIN_LOCK_UNLOCKED 宏 是 在 include/linux/spinlock_types.h 头 








文件 中 定义 ， 它 展开 到 __ARCH_SPIN_LOCK_UNLOCKED 宏 ， 而 ARCH_SPIN_LOCK_UNLOCKED 宏 又 
展开 到 零 或 者 无 锁 状 态 








#define __ARCH_SPIN_LOCK_UNLOCKED { {0}} 





AE 


信号 量 的 最 后 两 个 域 count 和 wait Blast 是 通过 现 有 (on coeds 链表 来 初始 化 。 第 
二 种 初始 化 信号 量 的 方式 是 将 信号 量 和 现 有 资源 数目 传送 sema_init HA ° 过 个 函数 
是 在 include/linux/semaphore.h 头 文件 中 定义 的 。 


static inline void sema init(struct semaphore *sem, int val) 


{ 
static struct lock_class_key _ key; 
*sem = (struct semaphore) __SEMAPHORE_INITIALIZER(*sem, val); 
lockdep_init_map(&sem->lock.dep_map, "semaphore->lock", & key, 0); 
} 


我 们 来 看 看 这 个 苑 数 是 如 何 实现 的 。 它 看 起 来 很 简单 。 郊 数 使 用 我 们 刚 看 到 的 

__SEMAPHORE_INITIALIZER 宏 对 传 入 的 信号 量 进行 初始 化 。 就 像 我 们 在 之 前 部 分 写 的 那样 ， 
我 们 将 会 跳 过 Linux 内 核 关 于 锁 验 证 的 部 分 。 从 现在 开始 我 们 知道 如 何 初始 化 一 个 信号 量 ， 
我 们 看 看 如 何 上 锁 和 解锁 。Linux 内 核 提供 了 如 下 操作 信号 量 的 API 


void down(struct semaphore *sem); 

void up(struct semaphore *sem); 

int down_interruptible(struct semaphore *sem); 

int down_killable(struct semaphore *sem); 

int down_trylock(struct semaphore *sem); 

int down_timeout(struct semaphore *sem, long jiffies); 


前 两 个 函数 dow 和 up 是 用 来 获取 或 释放 信号 量 。 down _interruptible 29 函数 试图 去 获 
取 一 个 信号 量 。 如 果 被 成 功 获取 ， 信号 量 的 计数 就 会 被 减少 并 且 锁 也 会 被 获取 。 同 时 当前 任 
务 也 会 被 调度 到 受阻 状态 ， sek TASK_INTERRUPTIBLE 标志 将 会 被 至 


位 。 TASK_INTERRUPTIBLE 表示 这 个 进程 也 许可 以 通过 信号 退回 到 销毁 状态 。 
down_killable 函数 和 down_interruptible 函数 提供 类 似 的 功能 ， 但 是 它 还 将 当前 进程 的 


TASK_KILLABLE 标志 置 位 。 这 表示 等 待 的 进程 可 以 被 杀 死 信号 中 断 。 


down_trylock 有 函数 和 spin_trylock 有 函数 相似 。 个 函数 试图 去 获取 一 个 锁 并 且 退 出 如 果 这 
个 操作 是 失败 的 。 在 这 个 例子 中 ， 想 获取 锁 ieee 待 。 最 后 的 down_timeout 函数 试图 
去 获取 一 个 锁 。 当 前 进程 将 会 被 中 断 进入 到 等 待 状态 当 超 过 传 入 的 可 等 待 时 间 。 除 此 之 外 你 
也 许 注意 到 ， 这 个 等 待 的 时 间 是 以 jiffies 计 数 。 


我 们 刚刚 看 了 信号 量 API 的 定义 。 我 们 从 down 函数 开始 看 。 这 个 函数 是 在 
kernel/locking/semaphore.c 源 代 码 定 义 的 。 我 们 来 看 看 函数 实现 : 


void down(struct semaphore *sem) 


{ 


unsigned long flags; 


raw_spin_lock_irqsave(&sem->lock, flags); 
if (likely(sem->count > 0)) 
sem->count--; 
else 
__down(sem); 
raw_spin_unlock_irqrestore(&sem->lock, flags); 


} 
EXPORT_SYMBOL (down) ; 


RM AA down 函数 起 始 处 定义 的 flag 变量 。 这 个 变量 将 会 传 入 
raw_spin_lock_irqsave 和 raw | spin_lock_irqrestore 宏 定 义 。 这 些 宏 是 在 
includellinux/spinlock.h 头 文件 定义 的 。 这 些 宏 用 来 保护 当前 的 计数 器 。 事 实 上 这 两 个 
宏 的 作用 和 spin lock 和 spin_unlock 宏 相似 。 只 不 过 这 组 宏 会 存储 / 重 置 当前 中 断 标志 并 
且 禁 止 中 断 。 


就 像 你 青 到 那样 ， down 函数 的 主要 就 是 通过 raw_spin_lock_irqsave 和 

raw_spin_unlock_irqrestore 宏 来 实现 的 。 我 们 通过 将 信号 量 的 计数 器 和 零 对 比 ， 如 果 计 数 
anes ， 我们 可 以 减少 这 个 计数 器 。 这 表示 我 们 已 经 获取 了 这 个 锁 。 否 则 如 果 计数 器 是 

这 表示 所 以 的 现 有 资源 都 已 经 被 占用 ， 我 们 需要 等 待 以 获取 这 个 锁 。 就 像 我 们 看 到 那 

> _ down 函数 将 会 被 调用 。 down 函数 是 在 相同 ) 的 源 代码 定义 的 ， 它 的 实现 看 起 来 如 
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static noinline void _ sched __down(struct semaphore *sem) 


{ 
__down_common(sem, TASK_UNINTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT ) ; 


— down 函数 仅仅 调用 了 down_common Wak > #ELATEZNA A 


@ semaphore ; 
e flag - 对 当前 任务 ; 
© timeout -最 长 等 待 信号 量 的 时 间 . 


在 我 们 看 __down_common 函数 之 前 ? 注意 down_trylock ， down_timeout 和 down_killable 
的 实现 也 都 是 基于 down common 2k © 


static noinline int _ sched __down_interruptible(struct semaphore *sem) 


{ 
return __down_common(sem, TASK_INTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT); 


_ down_killable 44x: 


static noinline int __sched _ down killable(struct semaphore *sem) 


{ 


return __down_common(sem, TASK_KILLABLE, MAX_SCHEDULE_TIMEOUT) ; 


__down_timeout LEE 


static noinline int _ sched __down_timeout(struct semaphore *sem, long timeout) 


{ 
return __down_common(sem, TASK_UNINTERRUPTIBLE, timeout); 


现在 我 们 来 看 看 down common WIA) KHL o 3K HA HH kernel/locking/semaphore.cM# X 


件 中 定义 的 。 这 个 函数 的 定义 从 以 下 两 个 本 地 变量 开始 。 


struct task_struct *task = current; 
struct semaphore_waiter waiter; 


第 一 个 变量 表示 当前 想 获取 本 地 处 理 器 锁 的 任务 。 current ZAA 
arch/x86/include/asm/current.h 头 文件 中 定义 的 。 


#define current get_current() 


get_current HAE current_task per-cpu 变量 的 值 。 


DECLARE_PER_CPU(struct task_struct *, current_task); 


static always inline struct task struct *get_current(void) 


{ 


return this_cpu_read_stable(current_task); 


w 
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第 二 个 变量 是 waiter 表示 了 一 个 semaphore.wait_list 列表 的 入 口 : 


struct semaphore_waiter { 
struct list_head list; 
struct task_struct *task; 
bool up; 


}; 


下 一 步 我 们 将 当前 进程 加 入 到 wait list 并 且 在 定义 如 下 变量 后 填充 


waiter 域 


list_add_tail(&waiter.list, &sem->wait_list); 
waiter.task = task; 
waiter.up = false; 


下 一 步 我 们 进入 到 如 下 的 无 限 循环 : 


for (;;) { 
if (signal_pending_state(state, task)) 
goto interrupted; 


if (unlikely(timeout <= 0)) 
goto timed_out; 


__set_task_state(task, state); 


raw_spin_unlock_irq(&sem->lock) ; 
timeout = schedule_timeout(timeout) ; 
raw_spin_lock_irq(&sem->lock); 


if (waiter.up) 
return 0; 


在 之 前 的 代码 中 我 们 将 waiter.up 设置 为 false ° Me 当 up 没有 设置 为 true 任务 将 会 
在 这 个 无 限 循 环 中 循环 。 这 个 循环 从 检查 当前 的 任务 是 否 处 于 pending 状态 开始 ， 也 就 是 说 
此 任务 的 标志 包含 TASK_INTERRUPTIBLE 或 者 TASK_WAKEKILL 标志 。 我 之 前 写 到 当 一 个 任务 在 

等 待 获取 一 个 信号 的 时 候 任 务 也 许可 以 被 【信号 】(https://en.wikipedia.org/wiki/Unix_signal) 
中 断 。 signal_pending_state 函数 是 在 include/linux/sched.h 原 文件 中 定义 的 ， 它 看 起 来 如 
FF: 


static inline int signal_pending_state(long state, struct task_struct *p) 
{ 
if (!(state & (TASK_INTERRUPTIBLE | TASK_WAKEKILL) ) ) 
return 0; 
if (!signal_pending(p) ) 
return 0; 


return (state & TASK_INTERRUPTIBLE) || fatal_signal_pending(p); 





REA state 427545 包含 TASK_INTERRUPTIBLE 或 者 TASK_WAKEKILL 人 位， 如果 不 包含 

这 两 个 位 ， 郊 数 退 出 。 下 一 步 我 们 检测 当前 任务 是 否 有 一 个 挂 起 信号 ， 如 果 没 有 挂 起 信号 函 
数 退 出 。 最 后 我 们 就 检测 state 位 掩 码 的 TASK_INTERRUPTIBLE 位 。 如 果 ， 我 们 任务 包含 一 
个 挂 起 信号 ， 我 们 将 会 跳 转 到 interrupted 标签 : 


interrupted: 
list_del(&waiter.list); 
return -EINTR; 


在 这 个 标签 中 ， 我 们 会 删除 等 待 锁 的 列表 ， 然 后 返回 -EINTR 错误 码 。 如果 一 个 任务 没有 挂 
起 信号 ， 我 们 检测 超时 是 否 小 于 等 于 零 。 


if (unlikely(timeout <= 0)) 
goto timed_out; 


我 们 跳 转 到 timed_out 标签 : 


timed out : 
list_del(&waiter.list); 
return -ETIME; 


这 个 标签 里 ， 我 们 继续 做 和 interrupted 一 样 的 事情 。 我 们 将 任务 从 锁 等 待 者 中 删除 ， 但 
返回 -ETIME 错误 码 。 如 果 一 个 任务 没有 挂 起 信号 而 且 给 予 的 超时 也 没有 过 期 ， 当 前 的 任 
将 会 被 设置 为 传 入 的 state 


ye pe BY 


__set_task_state(task, state); 


然后 调用 schedule timeout ÑX : 


raw_spin_unlock_irgq(&sem->lock) ; 
timeout = schedule_timeout(timeout) ; 
raw_spin_lock_irq(&sem->lock); 


这 个 函数 是 在 kernel/time/timer.c 代码 中 定义 的 。 schedule timeout 函数 将 当前 的 任务 置 为 
休眠 到 设置 的 超时 为 止 。 


这 就 是 所 有 关于 _ down_common 函数 。 如 果 一 个 函数 想 要 获取 一 个 已 经 被 其 它 任务 获取 的 
锁 ， 它 将 会 转 入 到 无 限 循 环 。 并 且 它 不 能 被 信号 中 断 ， 当 前 设置 的 超时 不 会 过 期 或 者 当前 持 
有 和 锁 的 任务 不 释放 它 。 现 在 我 们 来 看 看 up BAH LIM o 


up He down 函数 定义 在 同一 个 原文 件 。 这 个 函数 的 主要 功能 是 释放 锁 ， 这 个 函数 看 起 
来 : 


void up(struct semaphore *sem) 


{ 
unsigned long flags; 
raw_spin_lock_irqsave(&sem->lock, flags); 
if (likely(list_empty(&sem->wait_list) )) 
sem->count++; 
else 
—up(sem); 
raw_spin_unlock_irqrestore(&sem->lock, flags); 
} 


EXPORT_SYMBOL (up); 


它 看 起 来 和 down 元 数 相似 。 这 里 有 两 个 不 同 点 。 首 先 我 们 增加 semaphore 的 计数 。 如 果 等 
待 列表 是 空 的 ， 我 们 调用 在 当前 原文 件 中 定义 的 _ up 函数 。 如 果 等 待 列 表 不 是 空 的 ， 我 们 
需要 允许 列表 中 的 第 一 个 任务 去 获取 一 个 锁 : 


static noinline void __sched __up(struct semaphore *sem) 


{ 
struct semaphore_waiter *waiter = list_first_entry(&sem->wait_list, 
struct semaphore_waiter, list); 
list_del(&waiter->list); 
waiter->up = true; 
wake_up_process(waiter->task); 
} 


在 此 我 们 获取 待 序列 中 的 第 一 个 任务 ， 将 它 从 列表 中 删除 ， 将 它 的 waiter-up HAAB M 
此 刻 起 __down_common 函数 中 的 无 限 循 环 将 会 会 被 停止 ° wake_up_process 函数 将 会 在 __up 
函数 的 结尾 调用 。 我 们 从 down_common 函数 调用 的 schedule_timeout HAAA T 
schedule_timeout 函数 。 schedule_timeout 函数 将 当前 任务 置 于 睡眠 状态 直到 超时 等 待 。 现 
在 我 们 进程 也 许 会 睡眠 ， 我 们 需要 唤醒 。 这 就 是 为 什么 我 们 需要 从 kernel/sched/core.c MK 


码 中 调用 wake_up_process Bh BK 
这 就 是 所 有 的 信息 了 。 


这 就 是 Linux 内 核 中 关于 同步 原 语 的 第 三 部 分 的 终结 。 在 之 前 的 两 个 部 分 ， 我 们 已 经 见 到 了 
第 一 个 Linux 内 核 的 同步 原 语 aka ， 它 是 使 用 ticket spinlock 实现 并 且 用 于 很 短 时 间 
锁 。 在 这 个 部 分 我 们 见 到 了 sop 语 一 信号 量 ， 信 号 量 用 于 长 时 间 的 锁 ， 因 为 它 
导致 上 下 文 切换 。 在 下 一 部 分 ， 我 们 将 会 继续 深入 Linux 内 核 的 同步 原 语 并 且 讨 论 另 = 
步 原 语 一 LIFE © 

如 果 你 有 问题 或 者 建议 ， 请 在 twitter 0xAX 上 联系 我 ， 通 过 email 联 系 我 ， 或 者 创建 一 个 issue 
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Synchronization primitives in the Linux 
kernel. Part 4. 


Introduction 


This is the fourth part of the chapter which describes synchronization primitives in the Linux 
kernel and in the previous parts we finished to consider different types spinlocks and 
semaphore synchronization primitives. We will continue to learn synchronization primitives in 
this part and consider yet another one which is called - mutex which is stands for mutual 


EXclusion . 


As in all previous parts of this book, we will try to consider this synchronization primitive from 
the theoretical side and only than we will consider AP! provided by the Linux kernel to 
manipulate with mutexes . 


So, let's start. 


Concept of mutex 


We already familiar with the semaphore synchronization primitive from the previous part. It 
represented by the: 


struct semaphore { 


raw_spinlock_t lock; 
unsigned int count; 
struct list_head wait_list; 


}; 


structure which holds information about state of a lock and list of a lock waiters. Depends on 
the value of the count field, a semaphore can provide access to a resource of more than 
one wishing of this resource. The mutex concept is very similar to a semaphore concept. But 
it has some differences. The main difference between semaphore and mutex 
synchronization primitive is that mutex has more strict semantic. Unlike a semaphore , only 
one process may hold mutex atone time and only the owner ofa mutex may release or 
unlock it. Additional difference in implementation of lock API. The semaphore 
synchronization primitive forces rescheduling of processes which are in waiters list. The 
implementation of mutex lock API allows to avoid this situation and as a result expensive 
context switches. 


The mutex synchronization primitive represented by the following: 


struct mutex { 





atomic_t count; 
spinlock_t wait_lock; 
struct list_head wait_list; 
#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_MUTEX_SPIN_ON_OWNER) 
struct task_struct *owner; 


#endif 
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER 
struct optimistic_spin_queue osq; 





#endif 
#ifdef CONFIG_DEBUG_MUTEXES 

void *magic; 
#endif 
#ifdef CONFIG_DEBUG_LOCK_ALLOC 

struct lockdep_map dep_map; 
#endif 


}; 


structure in the Linux kernel. This structure is defined in the include/linux/mutex.h header file 

and contains similar to the semaphore structure set of fields. The first field of the mutex 

structure is - count . Value of this field represents state of a mutex . In a case when the 

value of the count fieldis 1 ,a mutex isin unlocked state. When the value of the count 

field is zero ,a mutex isinthe locked state. Additionally value of the count field may be 
negative . In this case a mutex isinthe locked state and has possible waiters. 


The next two fields of the mutex structure - wait_lock and wait_list are spinlock for the 
protection of a wait queue and list of waiters which represents this wait queue fora certain 
lock. As you may notice, the similarity of the mutex and semaphore structures ends. 
Remaining fields of the mutex structure, as we may see depends on different configuration 
options of the Linux kernel. 


The first field - owner represents process which acquired a lock. As we may see, existence 
of this field in the mutex structure depends on the coNFIG DEBUG MUTEXES Or 
CONFIG_MUTEX_SPIN_ON_OWNER kernel configuration options. Main point of this field and the 





next osq fields is support Of optimistic spinning which we will see later. The last two 
fields - magic and dep map are used only in debugging mode. The magic field is to storing 
a mutex related information for debugging and the second field - lockdep_map_ is for lock 
validator of the Linux kernel. 


Now, after we have considered the mutex structure, we may consider how this 
synchronization primitive works in the Linux kernel. As you may guess, a process which 
wants to acquire a lock, must to decrease value of the mutex->count if possible. And if a 


process wants to release a lock, it must to increase the same value. That's true. But as you 
may also guess, it is not so simple in the Linux kernel. 


Actually, when a process try to acquire a mutex , there three possible paths: 


e fastpath ; 
e midpath ; 


e Slowpath . 


which may be taken, depending on the current state of the mutex . The first path or 

fastpath is the fastest as you may understand from its name. Everything is easy in this 
case. Nobody acquired a mutex , so the value of the count field of the mutex structure 
may be directly decremented. In a case of unlocking of a mutex , the algorithm is the same. 
A process just increments the value of the count field of the mutex structure. Of course, all 
of these operations must be atomic. 


Yes, this looks pretty easy. But what happens if a process wants to acquire a mutex which 
is already acquired by other process? In this case, the control will be transferred to the 
second path - midpath . The midpath Or optimistic spinning tries to spin with already 
familiar for us MCS lock while the lock owner is running. This path will be executed only if 
there are no other processes ready to run that have higher priority. This path is called 

optimistic because the waiting task will not be sleep and rescheduled. This allows to avoid 
expensive context switch. 


In the last case, when the fastpath and midpath may not be executed, the last path - 

slowpath will be executed. This path acts like a semaphore lock. If the lock is unable to be 
acquired by a process, this process will be added to wait queue which is represented by 
the following: 


struct mutex_waiter { 


struct list_head WISE: 

struct task_struct *task; 
#ifdef CONFIG_DEBUG_MUTEXES 

void *magic; 
#endif 
J; 


structure from the include/linux/mutex.h header file and will be sleep. Before we will consider 
API which is provided by the Linux kernel for manipulation with mutexes , let's consider the 

mutex_waiter structure. If you have read the previous part of this chapter, you may notice 
that the mutex_waiter structure is similar to the semaphore_waiter structure from the 
kernel/locking/semaphore.c source code file: 


struct semaphore_waiter { 
struct list_head list; 
struct task_struct *task; 
bool up; 


}; 


It also contains list and task fields which are represent entry of the mutex wait queue. 
The one difference here that the mutex_waiter does not contains up field, but contains the 

magic field which depends on the coNFIG_DEBUG_MUTEXES kernel configuration option and 
used to store a mutex related information for debugging purpose. 


Now we know what is it mutex and how it is represented the Linux kernel. In this case, we 
may go ahead and start to look at the API which the Linux kernel provides for manipulation 


of mutexes . 


Mutex API 


Ok, in the previous paragraph we knew what is it mutex synchronization primitive and saw 
the mutex structure which represents mutex in the Linux kernel. Now it's time to consider 
API for manipulation of mutexes. Description of the mutex API is located in the 
include/linux/mutex.h header file. As always, before we will consider how to acquire and 
releasea mutex , we need to know how to initialize it. 


There are two approaches to initialize a mutex . The first is to do it statically. For this 
purpose the Linux kernel provides following: 


#define DEFINE_MUTEX(mutexname) \ 
struct mutex mutexname = _ MUTEX_INITIALIZER(mutexname) 


macro. Let's consider implementation of this macro. As we may see, the DEFINE_MUTEX 
macro takes name for the mutex and expands to the definition of the new mutex structure. 
Additionally new mutex structure get initialized with the _ MUTEX_INITIALIZER macro. Let's 
look at the implementation of the _ MUTEX_INITIALIZER : 


#define _ MUTEX_INITIALIZER(lockname) \ 

{ 
.count = ATOMIC_INIT(1), 
.wait_lock = __SPIN_LOCK_UNLOCKED(lockname.wait_lock), 
.wait_list = LIST_HEAD_INIT(lockname.wait_list) 


a a eg 


This macro is defined in the same header file and as we may understand it initializes fields 
of the mutex structure the initial values. The count field get initialized with the 1 which 
represents unlocked state of amutex. The wait_lock spinlock get initialized to the 
unlocked state and the last field wait list to empty doubly linked list. 


The second approach allows us to initialize a mutex dynamically. To do this we need to call 
the _ mutex_init function from the kerne!l/locking/mutex.c source code file. Actually, the 
__mutex_init function rarely called directly. Instead of the _ mutex_init , the: 


# define mutex_init (mutex) \ 
do { 
static struct lock_class_key _ key; 


a E 


__mutex_init((mutex), #mutex, &_ key); 
} while (0) 


macro is used. We may see that the mutex_init macro just defines the lock_class_key 
and call the _ mutex_init function. Let's look at the implementation of this function: 


void 
__mutex_init(struct mutex *lock, const char *name, struct lock_class_key *key) 


m~ 


atomic_set(&lock->count, 1); 
spin_lock_init(&lock->wait_lock); 
INIT_LIST_HEAD(&lock->wait_list); 
mutex_clear_owner (lock); 

#ifdef CONFIG_MUTEX_SPIN_ON_OWNER 
osq_lock_init(&lock->osq); 





#endif 
debug_mutex_init(lock, name, key); 


As we may see the _ mutex_init function takes three arguments: 


e lock -a mutex itself; 
e name -name of mutex for debugging purpose; 
e key - key for lock validator. 


At the beginning of the _ mutex_init function, we may see initialization of the mutex state. 
We setitto unlocked state with the atomic_set function which atomically set the give 
variable to the given value. After this we may see initialization of the spinlock to the 
unlocked state which will protect wait queue ofthe mutex and initialization of the wait 
queue ofthe mutex . After this we clear owner of the lock and initialize optimistic queue by 
the call of the osq_lock_init function from the include/linux/osq_lock.h header file. This 
function just sets the tail of the optimistic queue to the unlocked state: 


static inline bool osq_is_locked(struct optimistic spin queue *lock) 


{ 
return atomic_read(&lock->tail) != OSQ_UNLOCKED_VAL; 


In the end of the _ _mutex_init function we may see the call of the debug_mutex_init 
function, but as | already wrote in previous parts of this chapter, we will not consider 
debugging related stuff in this chapter. 


After the mutex structure is initialized, we may go ahead and will look at the lock and 
unlock API of mutex synchronization primitive. Implementation of mutex_lock and 
mutex_unlock functions located in the kernel/locking/mutex.c source code file. First of all 

let's start from the implementation of the mutex_lock . It looks: 


void __sched mutex_lock(struct mutex *lock) 

{ 
might_sleep(); 
__mutex_fastpath_lock(&lock->count, __mutex_lock_slowpath); 
mutex_set_owner(lock); 


We may see the call of the might_sleep macro from the include/linux/kernel.h header file at 
the beginning of the mutex_lock function. Implementation of this macro depends on the 
CONFIG_DEBUG_ATOMIC_SLEEP kernel configuration option and if this option is enabled, this 





macro just prints a stack trace if it was executed in atomic context. This macro is helper for 
debugging purposes. In other way this macro does nothing. 


After the might_sleep macro, we may see the call of the _ mutex_fastpath_lock function. 
This function is architecture-specific and as we consider x86_64 architecture in this book, 
the implementation of the _ _mutex_fastpath_lock is located in the 
arch/x86/include/asm/mutex_64.h header file. As we may understand from the name of the 

__mutex_fastpath_lock function, this function will try to acquire lock in a fast path or in other 
words this function will try to decrement the value of the count of the given mutex. 


Implementation of the _ mutex_fastpath_lock function consists from two parts. The first part 
is inline assembly statement. Let's look at it: 


asm_volatile_goto(LOCK_PREFIX " decl %0\n" 
jns %l[exit]\n" 
: "m" (v->counter ) 
:memor CG. 
EXIT)? 


First of all, let's pay attention to the asm volatile goto . This macro is defined in the 
include/linux/compiler-gcc.h header file and just expands to the two inline assembly 
statements: 


#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0) 


The first assembly statement contains goto specificator and the second empty inline 
assembly statement is barrier. Now let's return to the our inline assembly statement. As we 
may see it starts from the definition of the Lock_PREFIX macro which just expands to the 
lock instruction: 


#define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock; " 


As we already know from the previous parts, this instruction allows to execute prefixed 
instruction atomically. So, at the first step in the our assembly statement we try decrement 
value of the given mutex->counter . At the next step the jns instruction will execute jump at 
the exit label if the value of the decremented mutex->counter is not negative. The exit 
label is the second part of the _ mutex_fastpath_lock function and it just points to the exit 
from this function: 


exit: 
return; 


For this moment he implementation of the _ mutex_fastpath_lock function looks pretty easy. 
But the value of the mutex->counter may be negative after increment. In this case the: 


fail_fn(v); 


will be called after our inline assembly statement. The fail_fn is the second parameter of 

the __mutex_fastpath_lock function and represents pointer to function which represents 
midpath/slowpath paths to acquire the given lock. In our case the fail_fn is the 
__mutex_lock_slowpath function. Before we will look at the implementation of the 
__mutex_lock_slowpath function, let's finish with the implementation of the mutex_lock 

function. In the simplest way, the lock will be acquired successfully by a process and the 
__mutex_fastpath_lock will be finished. In this case, we just call the 


mutex_set_owner (lock); 


in the end of the mutex_lock . The mutex_set_owner function is defined in the 
kernel/locking/mutex.h header file and just sets owner of a lock to the current process: 


static inline void mutex_set_owner(struct mutex *lock) 


{ 


lock->owner = current; 


In other way, let's consider situation when a process which wants to acquire a lock is unable 
to do it, because another process already acquired the same lock. We already know that the 
__mutex_lock_slowpath function will be called in this case. Let's consider implementation of 
this function. This function is defined in the kernel/locking/mutex.c source code file and starts 

from the obtaining of the proper mutex by the mutex state given from the 


__mutex_fastpath_lock withthe container_of macro: 


__visible void _ sched 
__mutex_lock_slowpath(atomic_t *lock_count) 


{ 
struct mutex *lock = container_of(lock_count, struct mutex, count); 
__mutex_lock_common(lock, TASK_UNINTERRUPTIBLE, 0, 
NULL, _RET_IP_, NULL, 0); 
} 


and call the _ mutex_lock_common function with the obtained mutex . The 
__mutex_lock_common function starts from preemtion disabling until rescheduling: 


preempt_disable(); 


After this comes the stage of optimistic spinning. As we already know this stage depends on 
the CONFIG_MUTEX_SPIN_ON_OWNER kernel configuration option. If this option is disabled, we 





skip this stage and move at the last path- slowpath ofa mutex acquisition: 


if (mutex_optimistic_spin(lock, ww_ctx, use_ww_ctx)) { 
preempt_enable(); 
return 0; 


First of all the mutex_optimistic_spin function check that we don't need to reschedule or in 
other words there are no other tasks ready to run that have higher priority. If this check was 
successful we need to update mcs lock wait queue with the current spin. In this way only 
one spinner can complete for the mutex at one time: 


osq_lock(&lock->0sq) 


At the next step we start to spin in the next loop: 


while (true) { 
Owner = READ_ONCE(lock->owner); 


if (owner && !mutex_spin_on_owner(lock, owner) ) 
break; 


if (mutex_try_to_acquire(lock)) { 
lock_acquired(&lock->dep_map, ip); 


mutex_set_owner (lock); 
osq_unlock(&lock->0sq); 
return true: 


and try to acquire a lock. First of all we try to take current owner and if the owner exists (it 
may not exists in a case when a process already released a mutex) and we wait for it in the 

mutex_spin_on_owner function before the owner will release a lock. If new task with higher 
priority have appeared during wait of the lock owner, we break the loop and go to sleep. In 
other case, the process already may release a lock, so we try to acquire a lock with the 

mutex_try_to_acquired . If this operation finished successfully, we set new owner for the 
given mutex, removes ourself from the mcs wait queue and exit from the 

mutex_optimistic_spin function. At this state a lock will be acquired by a process and we 
enable preemtion and exit from the _ mutex_lock_common function: 


if (mutex_optimistic_spin(lock, ww_ctx, use_ww_ctx)) { 
preempt_enable(); 
return 0; 


That's all for this case. 


In other case all may not be so successful. For example new task may occur during we 
spinning in the loop from the mutex_optimistic_spin or even we may not get to this loop 
from the mutex_optimistic_spin in a case when there were task(s) with higher priority 
before this loop. Or finally the coNFIG MUTEX_SPIN_ON_OwNER kernel configuration option 





disabled. In this case the mutex_optimistic_spin will do nothing: 


#ifndef CONFIG_MUTEX_SPIN_ON_OWNER 
static bool mutex_optimistic_spin(struct mutex *lock, 





struct ww_acquire_ctx *ww_ctx, const bool use_ww_ctx) 


{ 
return false; 
} 
#endif 
‘| = J>] 








In all of these cases, the _ _mutex_lock_common function will acct like a semaphore . We try to 
acquire a lock again because the owner of a lock might already release a lock before this 
time: 


if (!mutex_is_locked(lock) && 
(atomic_xchg_acquire(&lock->count, 0) == 1)) 
goto skip_wait; 


In a failure case the process which wants to acquire a lock will be added to the waiters list 


list_add_tail(&waiter.list, &lock->wait_list); 
waiter.task = task; 


In a successful case we update the owner of a lock, enable preemption and exit from the 
__mutex_lock_common function: 


skip_wait: 
mutex_set_owner(lock); 
preempt_enable(); 
return 0; 


In this case a lock will be acquired. If can't acquire a lock for now, we enter into the following 
loop: 


for (77) { 
if (atomic_read(&lock->count) >= 0 && (atomic_xchg_acquire(&lock->count, -1) == 1) 
break; 


if (unlikely(signal_pending_state(state, task))) { 
ret = -EINTR; 
goto err; 


__set_task_state(task, state); 


schedule_preempt_disabled(); 


where try to acquire a lock again and exit if this operation was successful. Yes, we try to 
acquire a lock again right after unsuccessful try before the loop. We need to do it to make 
sure that we get a wakeup once a lock will be unlocked. Besides this, it allows us to acquire 
a lock after sleep. In other case we check the current process for pending signals and exit if 
the process was interrupted by a signal during wait for a lock acquisition. In the end of 
loop we didn't acquire a lock, so we set the task state for TASK_UNINTERRUPTIBLE and go to 
sleep with call of the schedule_preempt_disabled function. 


That's all. We have considered all three possible paths through which a process may pass 

when it will wan to acquire a lock. Now let's consider how mutex_unlock is implemented. 
When the mutex_unlock will be called by a process which wants to release a lock, the 
__mutex_fastpath_unlock will be called from the arch/x86/include/asm/mutex_64.h header 





file: 
void __sched mutex_unlock(struct mutex *lock) 
{ 
__mutex_fastpath_unlock(&lock->count, mutex_unlock_slowpath); 
} 


Implementation of the _ mutex_fastpath_unlock function is very similar to the 
implementation of the _ mutex_fastpath_lock function: 


static inline void __mutex_fastpath_unlock(atomic_t *v, 
void (*fail_fn)(atomic_t *)) 


{ 
asm_volatile_goto(LOCK_PREFIX " incl %0\n" 
Mu jg %l[exit]\n" 
"m" (v->counter ) 
umemo nya CC 
: exit); 
fail_fn(v); 
exit: 
return; 
} 


Actually, there is only one difference. We increment value if the mutex->count . So it will 
represent unlocked state after this operation. AS mutex released, but we have something 
inthe wait queue we need to update it. In this case the fail fn function will be called 
which is __mutex_unlock_slowpath . The _ mutex_unlock_slowpath function just gets the 








correct mutex instance by the given mutex->count and calls the 


mutex_unlock_common_slowpath function: 





mutex_unlock_slowpath(atomic_t *lock_count) 





struct mutex *lock = container_of(lock_count, struct mutex, count); 


mutex_unlock_common_slowpath(lock, 1); 





In the __mutex_unlock_common_slowpath function we will get the first entry from the wait queue 





if the wait queue is not empty and wakeup related process: 


if (!list_empty(&lock->wait_list)) { 
struct mutex_waiter *waiter = 
list_entry(lock->wait_list.next, struct mutex_waiter, list); 
wake_up_process(waiter ->task); 


After this, a mutex will be released by previous process and will be acquired by another 
process from a wait queue. 


That's all. We have considered main API for manipulation with mutexes : mutex_lock and 
mutex_unlock . Besides this the Linux kernel provides following API: 


© mutex_lock_interruptible 
© mutex_lock_killable 


© mutex_trylock . 


and corresponding versions of unlock prefixed functions. This part will not describe this 
API , because it is similar to corresponding API of semaphores . More about it you may 
read in the previous part. 


That's all. 


Conclusion 


This is the end of the fourth part of the synchronization primitives chapter in the Linux kernel. 
In this part we met with new synchronization primitive which is called - mutex . From the 
theoretical side, this synchronization primitive very similar on a semaphore. Actually, mutex 
represents binary semaphore. But its implementation differs from the implementation of 

semaphore in the Linux kernel. In the next part we will continue to dive into synchronization 
primitives in the Linux kernel. 


If you have questions or suggestions, feel free to ping me in twitter OxAX, drop me email or 
just create issue. 


Please note that English is not my first language and I am really sorry for any 
inconvenience. If you found any mistakes please send me PR to linux-insides. 
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Synchronization primitives in the Linux 
kernel. Part 5. 


Introduction 


This is the fifth part of the chapter which describes synchronization primitives in the Linux 

kernel and in the previous parts we finished to consider different types spiniocks, semaphore 
and mutex synchronization primitives. We will continue to learn synchronization primitives in 
this part and start to consider special type of synchronization primitives - readers—writer lock. 


The first synchronization primitive of this type will be already familiar for us - semaphore. As 
in all previous parts of this book, before we will consider implementation of the 

reader/writer semaphores in the Linux kernel, we will start from the theoretical side and will 
try to understand what is the difference between reader/writer semaphores and normal 


semaphores . 


So, let's start. 


Reader/Writer semaphore 


Actually there are two types of operations may be performed on the data. We may read data 
and make changes in data. Two fundamental operations - read and write . Usually (but 
not always), read operation is performed more often than write operation. In this case, it 
would be logical to we may lock data in such way, that some processes may read locked 
data in one time, on condition that no one will not change the data. The readers/writer lock 
allows us to get this lock. 


When a process which wants to write something into data, all other writer and reader 
processes will be blocked until the process which acquired a lock, will not release it. When a 
process reads data, other processes which want to read the same data too, will not be 
locked and will be able to do this. As you may guess, implementation of the reader/writer 
semaphore is based on the implementation of the normal semaphore . We already familiar with 
the semaphore synchronization primitive from the third part of this chapter. From the 
theoretical side everything looks pretty simple. Let's look how reader/writer semaphore is 
represented in the Linux kernel. 


The semaphore is represented by the: 


struct semaphore { 


raw_spinlock_t lock; 
unsigned int count; 
struct list_head wait_list; 


}; 


structure. If you will look in the include/linux/rwsem.h header file, you will find definition of the 
rw_semaphore structure which represents reader/writer semaphore in the Linux kernel. Let's 
look at the definition of this structure: 


#ifdef CONFIG_RWSEM_GENERIC_SPINLOCK 
#include <linux/rwsem-spinlock.h> 
#else 
struct rw_semaphore { 
long count; 
struct list_head wait_list; 
raw_spinlock_t wait_lock; 
#ifdef CONFIG_RWSEM_SPIN_ON_OWNER 
struct optimistic_spin_queue osq; 





struct task_struct *owner; 
#endif 
#ifdef CONFIG_DEBUG_LOCK_ALLOC 

struct lockdep_map dep_map; 
#endif 


}; 


Before we will consider fields of the rw_semaphore structure, we may notice, that declaration 
of the rw_semaphore structure depends on the cCoONFIG_RWSEM_GENERIC_SPINLOCK kernel 
configuration option. This option is disabled for the x86 64 architecture by default. We can 
be sure in this by looking at the corresponding kernel configuration file. In our case, this 
configuration file is - arch/x86/um/Kconfig: 


config RWSEM_XCHGADD_ALGORITHM 
def_bool 64BIT 


config RWSEM_GENERIC_SPINLOCK 
def_bool !RWSEM_XCHGADD_ALGORITHM 


So, as this book describes only x86_64 architecture related stuff, we will skip the case when 
the CONFIG_RWSEM_GENERIC_SPINLOcCK kernel configuration is enabled and consider definition of 
the rw_semaphore structure only from the include/linux/rwsem.h header file. 


If we will take a look at the definition of the rw_semaphore structure, we will notice that first 
three fields are the same that in the semaphore structure. It contains count field which 
represents amount of available resources, the wait_list field which represents doubly 


linked list of processes which are waiting to acquire a lock and wait_lock spinlock for 
protection of this list. Notice that rw_semaphore.count field is long type unlike the same 
field in the semaphore structure. 


The count field of a rw_semaphore structure may have following values: 


© 0©x0000000000000000 - reader/writer semaphore is in unlocked state and no one is 
waiting for a lock; 

e 0x000000000000000X - x readers are active or attempting to acquire a lock and no 
writer waiting; 

e oxffffffffoee000ex - may represent different cases. The first is - x readers are active 
or attempting to acquire a lock with waiters for the lock. The second is - one writer 
attempting a lock, no waiters for the lock. And the last - one writer is active and no 
waiters for the lock; 

e oxffffffffoe000001 - may represented two different cases. The first is - one reader is 
active or attempting to acquire a lock and exist waiters for the lock. The second case is 
one writer is active or attempting to acquire a lock and no waiters for the lock; 

e 0xffffffff00000000 - represents situation when there are readers or writers are 
queued, but no one is active or is in the process of acquire of a lock; 

e 9xfffffffe00000001 -a writer is active or attempting to acquire a lock and waiters are in 
queue. 


So, besides the count field, all of these fields are similar to fields of the semaphore 
structure. Last three fields depend on the two configuration options of the Linux kernel: the 


CONFIG_RWSEM_SPIN_ON_OWNER and CONFIG_DEBUG_LOCK_ALLoc . The first two fields may be 





familiar us by declaration of the mutex structure from the previous part. The first osq field 
represents MCS lock spinner for optimistic spinning and the second represents process 
which is current owner of a lock. 


The last field of the rw_semaphore structure is - dep_map - debugging related, and as | 
already wrote in previous parts, we will skip debugging related stuff in this chapter. 


That's all. Now we know a little about what is it reader/writer lock in general and 
reader/writer semaphore in particular. Additionally we saw how a reader/writer semaphore 
is represented in the Linux kernel. In this case, we may go ahead and start to look at the API 

which the Linux kernel provides for manipulation of reader/writer semaphores . 


Reader/Writer semaphore API 


So, we know alittle about reader/writer semaphores from theoretical side, let's look on its 
implementation in the Linux kernel. All reader/writer semaphores related API is located in 
the include/linux/rwsem.h header file. 


As always Before we will consider an AP! of the reader/writer semaphore mechanism in the 
Linux kernel, we need to know how to initialize the rw _semaphore structure. As we already 
saw in previous parts of this chapter, all synchronization primitives may be initialized in two 
ways: 


e statically ; 


e dynamically . 


And reader/writer semaphore is not an exception. First of all, let's take a look at the first 
approach. We may initialize rw_semaphore structure with the help of the DECLARE_RWSEM 
macro in compile time. This macro is defined in the include/linux/rwsem.h header file and 
looks: 


#define DECLARE_RWSEM(name) \ 
struct rw_semaphore name = __RWSEM_INITIALIZER(name) 


As we may see, the DECLARE_RWSEM macro just expands to the definition of the 
rw_semaphore structure with the given name. Additionally new rw_semaphore structure is 
initialized with the value of the _ RWSEM_INITIALIZER macro: 


#define __RWSEM_INITIALIZER(name) \ 
{ 
.count = RWSEM_UNLOCKED_VALUE, 
-wait_list = LIST_HEAD_INIT((name).wait_list), 
-wait_lock = RAW_SPIN_LOCK_UNLOCKED(name.wait_lock) 
__RWSEM_OPT_INIT(name) 
RWSEM_DEP_MAP_INIT(name) 





ee re ee 





and expands to the initialization of fields of rw_semaphore structure. First of all we initialize 
count field of the rw_semaphore structure to the unlocked state with 
RWSEM_UNLOCKED_VALUE macro from the arch/x86/include/asm/rwsem.h architecture specific 
header file: 


#define RWSEM_UNLOCKED_VALUE OxO00000000L 


After this we initialize list of a lock waiters with the empty linked list and spinlock for 
protection of this list with the unlocked state too. The _ RwsEM opPT_INIT macro depends on 





the state of the conFIG_RWSEM_SPIN_ON_owNER kernel configuration option and if this option is 
enabled it expands to the initialization of the osq and owner fields of the rw_semaphore 
structure. As we already saw above, the coNFIG RWSEM SPIN_ON_OWNER kernel configuration 





option is enabled by default for x86 64 architecture, so let's take a look at the definition of 
the _ _RWSEM_OPT_INIT macro: 


#ifdef CONFIG_RWSEM_SPIN_ON_OWNER 

#define __RWSEM_OPT_INIT(lockname) , .osq = OSQ_LOCK_UNLOCKED, .owner = NULL 
#else 

#define __RWSEM_OPT_INIT(lockname) 
#endif 





As we may see, the __RWSEM_oPT_INIT macro initializes the MCS lock lock with unlocked 
state and initial owner ofa lock with NuLL . From this moment, a rw_semaphore structure 
will be initialized in a compile time and may be used for data protection. 


The second way to initialize a rw_semaphore structure is dynamically or use the 

init_rwsem macro from the include/linux/rwsem.h header file. This macro declares an 
instance of the lock_class_key which is related to the lock validator of the Linux kernel and 
to the call of the __init_rwsem function with the given reader/writer semaphore : 


#define init_rwsem(sem) \ 
do { 
static struct lock_class_key _ key; 


ee ee ee 


__init_rwsem((sem), #sem, & key); 
} while (0) 


If you will start definition of the _ init_rwsem function, you will notice that there are couple 
of source code files which contain it. As you may guess, sometimes we need to initialize 
additional fields of the rw_semaphore structure, like the osq and owner . But sometimes 
not. All of this depends on some kernel configuration options. If we will look at the 
kernel/locking/Makefile makefile, we will see following lines: 


obj -$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem-spinlock.o 
obj -$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem-xadd.o 


As we already know, the Linux kernel for x86 64 architecture has enabled 
CONFIG_RWSEM_XCHGADD_ALGORITHM kernel configuration option by default: 


config RWSEM_XCHGADD_ALGORITHM 
def_bool 64BIT 


in the arch/x86/um/Kconfig kernel configuration file. In this case, implementation of the 
__init_rwsem function will be located in the kernel/locking/rwsem-xadd.c source code file 
for us. Let's take a look at this function: 


void __init_rwsem(struct rw_semaphore *sem, const char *name, 
struct lock_class_key *key) 
{ 
#ifdef CONFIG_DEBUG_LOCK_ALLOC 
debug_check_no_locks_freed((void *)sem, sizeof(*sem)); 





lockdep_init_map(&sem->dep_map, name, key, 0); 
#endif 
sem->count = RWSEM_UNLOCKED_VALUE; 
raw_spin_lock_init(&sem->wait_lock); 
INIT_LIST_HEAD(&sem->wait_list); 
#ifdef CONFIG_RWSEM_SPIN_ON_OWNER 
sem->owner = NULL; 





osq_lock_init(&sem->0sq); 
#endif 
} 


We may see here almost the same as in __RWSEM_INITIALIZER macro with difference that all 
of this will be executed in runtime. 


So, from now we are able to initialize a reader/writer semaphore let's look at the lock and 
unlock API. The Linux kernel provides following primary API to manipulate reader/writer 


semaphores : 


e void down_read(struct rw_semaphore *sem) - lock for reading; 

e int down_read_trylock(struct rw_semaphore *sem) -try lock for reading; 
e void down_write(struct rw_semaphore *sem) -lock for writing; 

e int down_write_trylock(struct rw_semaphore *sem) -try lock for writing; 
e void up_read(struct rw_semaphore *sem) -release a read lock; 


e void up_write(struct rw_semaphore *sem) -release a write lock; 


Let's start as always from the locking. First of all let's consider implementation of the 

down_write function which executes a try of acquiring of a lock for write . This function is 
kernel/locking/rwsem.c source code file and starts from the call of the macro from the 
include/linux/kernel.h header file: 


void __sched down_write(struct rw_semaphore *sem) 
{ 
might_sleep(); 
rwsem_acquire(&sem->dep_map, ©, ©, _RET_IP_); 


LOCK_CONTENDED(sem, _ down write trylock, _ down_write); 
rwsem_set_owner(sem); 


We already met the might_sleep macro in the previous part. In short words, Implementation 
of the might_sleep macro depends on the coNFIG DEBUG ATOMIC SLEEP kernel configuration 





option and if this option is enabled, this macro just prints a stack trace if it was executed in 
atomic context. As this macro is mostly for debugging purpose we will skip it and will go 
ahead. Additionally we will skip the next macro from the down_read function - 

rwsem_acquire which is related to the lock validator of the Linux kernel, because this is topic 
of other part. 


The only two things that remained in the down_write function is the call of the 
LOCK_CONTENDED macro which is defined in the include/linux/lockdep.h header file and setting 
of owner of a lock with the rwsem_set_owner function which sets owner to currently running 


process: 
static inline void rwsem_set_owner(struct rw_semaphore *sem) 
{ 
sem->owner = current; 
} 


As you already may guess, the Lock_coNTENDED macro does all job for us. Let's look at the 
implementation of the Lock_coNTENDED macro: 


#define LOCK_CONTENDED(_lock, try, lock) \ 
lock(_lock) 


As we may see it just calls the lock function which is third parameter of the 
LOCK_CONTENDED macro with the given rw_semaphore . In our case the third parameter of the 
LOCK_CONTENDED macro is the _ down write function which is architecture specific function 

and located in the arch/x86/include/asm/rwsem.h header file. Let's look at the 

implementation of the _ down_write function: 


static inline void __down_write(struct rw_semaphore *sem) 


{ 


__down_write_nested(sem, 0); 


} 


which just executes a call of the _ down write nested function from the same source code 
file. Let's take a look at the implementation of the _ down_write_nested function: 


static inline void _ down write nested(struct rw_semaphore *sem, int subclass) 


{ 
long tmp; 


asm volatile("# beginning down_write\n\t" 








LOCK_PREFIX "  xadd %1, (%2)\n\t" 
" test " _ ASM _SEL(%w1,%k1) "," __ASM_SEL(%w1,%k1) "\n\t" 
are 1f\n" 
" call call_rwsem_down_write_failed\n" 
"a:\n" 
"# ending down_write" 
"+m" (sem->count), "=d" (tmp) 
"a" (sem), "1" (RWSEM_ACTIVE_WRITE_BIAS) 
"memory", "cc"); 


As for other synchronization primitives which we saw in this chapter, usually 1ock/unlock 
functions consists only from an inline assembly statement. As we may see, in our case the 
same for _ down write nested function. Let's try to understand what does this function do. 
The first line of our assembly statement is just a comment, let's skip it. The second like 
contains Lock_PREFIX which will be expanded to the LOCK instruction as we already know. 
The next xadd instruction executes add and exchange operations. In other words, xadd 
instruction adds value of the RWSEM_ACTIVE_WRITE_BIAS : 








#define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS) 
#define RWSEM_WAITING_BIAS ( - RWSEM_ACTIVE_MASK-1) 
#define RWSEM_ACTIVE_BIAS 0x00000001L 


or oxffffffffoeeeeee1 tothe count ofthe given reader/writer semaphore and returns 
previous value of it. After this we check the active mask in the rw_semaphore->count . If it was 
zero before, this means that there were no-one writer before, so we acquired a lock. In other 
way we Call the call_rwsem_down_write_failed function from the arch/x86/lib/rwsem.S 








assembly file. The the call_rwsem_down_write_failed function just calls the 
rwsem_down_write failed function from the kernel/locking/rwsem-xadd.c source code file 
anticipatorily save general purpose registers: 


ENTRY (call_rwsem_down_write_failed) 
FRAME_BEGIN 
save_common_regs 





movdq %rax, %rdi 

call rwsem_down_write_failed 
restore_common_regs 

FRAME_END 

ret 
ENDPROC(call_rwsem_down_write_failed) 





The rwsem_down_write_failed function starts from the atomic update of the count value: 





__visible 
struct rw_semaphore _ sched *rwsem_down_write_failed(struct rw_semaphore *sem) 
{ 
count = rwsem_atomic_update(-RWSEM_ACTIVE_WRITE_BIAS, sem); 
} 


with the -RWSEM_ACTIVE_WRITE_BIAS value. The rwsem_atomic_update function is defined in 





the arch/x86/include/asm/rwsem.h header file and implement exchange and add logic: 


static inline long rwsem_atomic_update(long delta, struct rw_semaphore *sem) 


{ 


return delta + xadd(&sem->count, delta); 


This function atomically adds the given delta to the count and returns old value of the 
count. After this it just returns sum of the given delta and old value of the count field. In 
our case we undo write bias from the count as we didn't acquire a lock. After this step we 
try todo optimistic spinning by the call of the rwsem_optimistic_spin function: 


if (rwsem_optimistic_spin(sem) ) 
return sem; 


We will skip implementation of the rwsem_optimistic_spin function, as it is similar on the 

mutex_optimistic_spin function which we saw in the previous part. In short words we check 
existence other tasks ready to run that have higher priority in the rwsem_optimistic_spin 
function. If there are such tasks, the process will be added to the MCS waitqueue and start 
to spin in the loop until a lock will be able to be acquired. If optimistic spinning is disabled, 
a process will be added to the and marked as waiting for write: 


waiter.task = current; 
waiter.type = RWSEM_WAITING_FOR_WRITE; 


if (list_empty(&sem->wait_list) ) 
waiting = false; 


list_add_tail(&waiter.list, &sem->wait_list); 


waiters list and start to wait until it will successfully acquire the lock. After we have added a 
process to the waiters list which was empty before this moment, we update the value of the 


rw_semaphore->count With the RWSEM_WAITING_BIAS : 


count = rwsem_atomic_update(RWSEM_WAITING_BIAS, sem); 


with this we mark rw_semaphore->counter that it is already locked and exists/waits one 

writer which wants to acquire the lock. In other way we try to wake reader processes 
from the wait queue that were queued before this writer process and there are no active 
readers. In the end of the rwsem_down_write_failed a writer process will go to sleep which 
didn't acquire a lock in the following loop: 


while (true) { 

if (rwsem_try_write_lock(count, sem)) 
break; 

raw_spin_unlock_irq(&sem->wait_lock) ; 

do { 
schedule(); 
set_current_state(TASK_UNINTERRUPTIBLE) ; 

} while ((count = sem->count) & RWSEM_ACTIVE_MASK); 

raw_spin_lock_irgq(&sem->wait_lock); 


| will skip explanation of this loop as we already met similar functional in the previous part. 


That's all. From this moment, our writer process will acquire or not acquire a lock depends 
on the value of the rw _semaphore->count field. Now if we will look at the implementation of 
the down_read function which executes a try of acquiring of a lock. We will see similar 
actions which we saw in the down_write function. This function calls different debugging 
and lock validator related functions/macros: 


void __sched down_read(struct rw_semaphore *sem) 


{ 
might_sleep(); 
rwsem_acquire_read(&sem->dep_map, ©, 9, _RET_IP_); 
LOCK_CONTENDED(sem, __down_read_trylock, __down_read); 
} 


and does all job in the _ down_read function. The _ down_read consists of inline assembly 
statement: 


static inline void __down_read(struct rw_semaphore *sem) 





{ 
asm volatile("# beginning down_read\n\t" 
LOCK_PREFIX _ASM_INC "(%1)\n\t" 
" jns 1f\n" 
" call call_rwsem_down_read_failed\n" 
ey NA Nts 
"# ending down_read\n\t" 
"+m" (sem->count ) 
"a" (sem) 
"memory", "cc"); 
} 


which increments value of the given rw_semaphore->count and call the 
call_rwsem_down_read_failed if this value is negative. In other way we jump at the label 1: 





and exit. After this read lock will be successfully acquired. Notice that we check a sign of 
the count value as it may be negative, because as you may remember most significant 
word of the rw_semaphore->count contains negated number of active writers. 


Let's consider case when a process wants to acquire a lock for read operation, but it is 
already locked. In this case the call_rwsem_down_read_failed function from the 





arch/x86/lib/rwsem.S assembly file will be called. If you will look at the implementation of this 
function, you will notice that it does the same that call_rwsem_down_read_failed function 





does. Except it calls the rwsem_down_read_failed function instead of 
rwsem_dow_write_failed . Now let's consider implementation of the rwsem_down_read_failed 
function. It starts from the adding a process to the wait queue and updating of value of the 


rw_semaphore->counter 


long adjustment = -RWSEM_ACTIVE_READ_BIAS; 


waiter.task tsk; 
waiter.type = RWSEM_WAITING_FOR_READ; 


if (list_empty(&sem->wait_list) ) 
adjustment += RWSEM_WAITING_BIAS; 
list_add_tail(&waiter.list, &sem->wait_list); 


count = rwsem_atomic_update(adjustment, sem); 


Notice that if the wait queue was empty before we clear the rw_semaphore->counter and 
undo read bias in other way. At the next step we check that there are no active locks and 
we are first in the wait queue we need to join currently active reader processes. In other 
way we go to sleep until a lock will not be able to acquired. 


That's all. Now we know how reader and writer processes will behave in different cases 
during a lock acquisition. Now let's take a short look at unlock operations. The up_read 
and up_write functions allows us to unlocka reader or writer lock. First of all let's take 
a look at the implementation of the up_write function which is defined in the 
kernel/locking/rwsem.c source code file: 


void up_write(struct rw_semaphore *sem) 


{ 


rwsem_release(&sem->dep_map, 1, _RET_IP_); 


rwsem_clear_owner(sem); 
__up_write(sem); 


First of all it calls the rwsem_release macro which is related to the lock validator of the Linux 
kernel, so we will skip it now. And at the next line the rwsem_clear_owner function which as 
you may understand from the name of this function, just clears the owner field of the given 


rw_semaphore 


static inline void rwsem_clear_owner(struct rw_semaphore *sem) 


{ 


sem->owner = NULL; 


The _ up write function does all job of unlocking of the lock. The _up_write is 
architecture-specific function, so for our case it will be located in the 
arch/x86/include/asm/rwsem.h source code file. If we will take a look at the implementation 


of this function, we will see that it does almost the same that _ down_write function, but 
conversely. Instead of adding of the RwsEM_ ACTIVE WRITE_ BIAS to the count , we subtract the 





same value and check the sign of the previous value. 


If the previous value of the rw_semaphore->count is not negative, a writer process released a 
lock and now it may be acquired by someone else. In other case, the rw_semaphore->count 
will contain negative values. This means that there is at least one writer in a wait queue. 
In this case the call_rwsem_wake function will be called. This function acts like similar 
functions which we already saw above. It store general purpose registers at the stack for 
preserving and call the rwsem wake function. 


First of all the rwsem wake function checks if a spinner is present. In this case it will just 
acquire a lock which is just released by lock owner. In other case there must be someone in 
the wait queue and we need to wake or writer process if it exists at the top of the wait 
queue Orall reader processes. The up_read function which release a reader lock acts in 
similar way like up_write , but with a little difference. Instead of subtracting of 





RWSEM_ACTIVE_WRITE_BIAS from the rw_semaphore->count , itsubtracts 1 from it, because 
less significant word of the count contains number active locks. After this it checks sign 
of the count and calls the rwsem wake like _ up write ifthe count is negative or in other 
way lock will be successfully released. 


That's all. We have considered API for manipulation with reader/writer semaphore : 

up_read/up_write and down_read/down_write . We saw that the Linux kernel provides 
additional API, besides this functions, like the , and etc. But | will not consider 
implementation of these function in this part because it must be similar on that we have seen 
in this part of except few subtleties. 


Conclusion 


This is the end of the fifth part of the synchronization primitives chapter in the Linux kernel. 
In this part we met with special type of semaphore - readers/writer Semaphore which 
provides access to data for multiply process to read or for one process to writer. In the next 
part we will continue to dive into synchronization primitives in the Linux kernel. 


If you have questions or suggestions, feel free to ping me in twitter OxAX, drop me email or 
just create issue. 


Please note that English is not my first language and I am really sorry for any 
inconvenience. If you found any mistakes please send me PR to linux-insides. 
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Synchronization primitives in the Linux 
kernel. Part 6. 


Introduction 


This is the sixth part of the chapter which describes synchronization primitives) in the Linux 
kernel and in the previous parts we finished to consider different readers-writer lock 
synchronization primitives. We will continue to learn synchronization primitives in this part 
and start to consider a similar synchronization primitive which can be used to avoid the 
writer starvation problem. The name of this synchronization primitive is - seqlock or 


sequential locks . 


We know from the previous part that readers-writer lock is a special lock mechanism which 
allows concurrent access for read-only operations, but an exclusive lock is needed for 
writing or modifying data. As we may guess, it may lead to a problem which is called writer 
starvation . In other words, a writer process can't acquire a lock as long as at least one 
reader process which aqcuired a lock holds it. So, in the situation when contention is high, it 
will lead to situation when a writer process which wants to acquire a lock will wait for it for a 
long time. 


The seqlock synchronization primitive can help solve this problem. 


As in all previous parts of this book, we will try to consider this synchronization primitive from 
the theoretical side and only than we will consider AP! provided by the Linux kernel to 
manipulate with seqlocks . 


So, let's start. 


Sequential lock 


So, what is a seqlock synchronization primitive and how does it work? Let's try to answer 
on these questions in this paragraph. Actually sequential locks were introduced in the 
Linux kernel 2.6.x. Main point of this synchronization primitive is to provide fast and lock-free 
access to shared resources. Since the heart of sequential lock synchronization primitive is 
spiniock synchronization primitive, sequential locks work in situations where the protected 
resources are small and simple. Additionally write access must be rare and also should be 
fast. 


Work of this synchronization primitive is based on the sequence of events counter. Actually a 

sequential lock allows free access to a resource for readers, but each reader must check 
existence of conflicts with a writer. This synchronization primitive introduces a special 
counter. The main algorithm of work of sequential locks is simple: Each writer which 
acquired a sequential lock increments this counter and additionally acquires a spinlock. 
When this writer finishes, it will release the acquired spinlock to give access to other writers 
and increment the counter of a sequential lock again. 


Read only access works on the following principle, it gets the value of a sequential lock 
counter before it will enter into critical section and compares it with the value of the same 

sequential lock counter at the exit of critical section. If their values are equal, this means 
that there weren't writers for this period. If their values are not equal, this means that a writer 
has incremented the counter during the critical section. This conflict means that reading of 
protected data must be repeated. 


That's all. As we may see principle of work of sequential locks is simple. 


unsigned int seq_counter_value; 


do { 
seq_counter_value = get_seq_counter_val(&the_lock); 


} while (__retry__); 


Actually the Linux kernel does not provide get_seq_counter_val() function. Here it is just a 
stub. Like a _retry_ too. As | already wrote above, we will see actual the AP! for this in 
the next paragraph of this part. 


Ok, now we know whata seqlock synchronization primitive is and how it is represented in 
the Linux kernel. In this case, we may go ahead and start to look at the AP! which the Linux 
kernel provides for manipulation of synchronization primitives of this type. 


Sequential lock API 


So, now we know a little about sequentional lock synchronization primitive from theoretical 
side, let's look at its implementation in the Linux kernel. All sequentional locks API are 
located in the include/linux/seqlock.h header file. 


First of all we may see that the a sequential lock machanism is represented by the 
following type: 


typedef struct { 
struct seqcount seqcount; 
spinlock_t lock; 

} seqlock_t; 


As we may see the seqlock_t provides two fields. These fields represent a sequential lock 
counter, description of which we saw above and also a spinlock which will protect data from 
other writers. Note that the seqcount counter represented as seqcount type. The 

seqcount is structure: 


typedef struct seqcount { 
unsigned sequence; 

#ifdef CONFIG_DEBUG_LOCK_ALLOC 
struct lockdep_map dep_map; 

#endif 

} seqcount_t; 


which holds counter of a sequential lock and lock validator related field. 


As always in previous parts of this chapter, before we will consider an AP! of sequential 
lock mechanism in the Linux kernel, we need to know how to initialize an instance of 
seqlock_t . 


We saw in the previous parts that often the Linux kernel provides two approaches to execute 
initialization of the given synchronization primitive. The same situation with the seqlock_t 
structure. These approaches allows to initialize a seqlock_t in two following: 


èe statically 


© dynamically 


ways. Let's look at the first approach. We are able to intialize a seqlock_t statically with the 
DEFINE_SEQLOCK macro: 


#define DEFINE_SEQLOCK(x) \ 
seqlock_t x = __SEQLOCK_UNLOCKED(x) 


which is defined in the include/linux/seqlock.h header file. As we may see, the 
DEFINE_SEQLOCK macro takes one argument and expands to the definition and initialization of 

the seqlock_t structure. Initialization occurs with the help of the _ seEQLock_UNLOcKED macro 

which is defined in the same source code file. Let's look at the implementation of this macro: 


#define __SEQLOCK_UNLOCKED(1lockname ) \ 


{ \ 

.seqcount = SEQCNT_ZERO(lockname), \ 

.lock = __SPIN_LOCK_UNLOCKED(lockname) \ 
} 


As we may see the, _ seQLock UNLOCKED macro executes initialization of fields of the given 
seqlock_t Structure. The first field is seqcount initialized with the seQcNT ZzERO macro 
which expands to the: 


#define SEQCNT_ZERO(lockname) { .sequence = ©, SEQCOUNT_DEP_MAP_INIT(lockname) } 


So we just initialize counter of the given sequential lock to zero and additionally we can see 
lock validator related initialization which depends on the state of the 
CONFIG_DEBUG_LOCK_ALLoc kernel configuration option: 


#ifdef CONFIG_DEBUG_LOCK_ALLOC 
# define SEQCOUNT_DEP_MAP_INIT(lockname) \ 
.dep_map = { .name = #lockname } \ 


#else 
# define SEQCOUNT_DEP_MAP_INIT(lockname) 


#endif 


As | already wrote in previous parts of this chapter we will not consider debugging and lock 
validator related stuff in this part. So for now we just skip the SEQcoUNT_DEP_MAP_INIT macro. 
The second field of the given seqlock_t iS lock initialized with the _ SPIN_LOCK_UNLOCKED 
macro which is defined in the include/linux/spinlock_types.h header file. We will not consider 
implementation of this macro here as it just initialize rawspiniock with architecture-specific 
methods (More abot spinlocks you may read in first parts of this chapter). 


We have considered the first way to initialize a sequential lock. Let's consider second way to 
do the same, but do it dynamically. We can initialize a sequentional lock with the 
seqlock_init macro which is defined in the same include/linux/seqlock.h header file. 


Let's look at the implementation of this macro: 


#define seqlock_init(x) \ 


do { \ 
seqcount_init(&(x)->seqcount); \ 
spin_lock_init(&(x)->lock); \ 

} while (0) 


As we may see, the seqlock_init expands into two macros. The first macro seqcount_init 
takes counter of the given sequential lock and expands to the call of the _ seqcount_init 


function: 
# define seqcount_init(s) N 
do { \ 
static struct lock_class_key _ key; N 
__seqcount_init((s), #s, & key); \ 
} while (0) 


from the same header file. This function 


static inline void __seqcount_init(seqcount_t *s, const char *name, 
struct lock_class_key *key) 


lockdep_init_map(&s->dep_map, name, key, ©); 
s->sequence = 0; 


just initializes counter of the given seqcount_t with zero. The second call from the 
seqlock_init macro is the call of the spin_lock_init macro which we saw in the first part 
of this chapter. 


So, now we know how to initialize a sequential lock , now let's look at how to use it. The 
Linux kernel provides following AP! to manipulate sequential locks : 


static inline unsigned read_seqbegin(const seqlock_t *sl); 
static inline unsigned read_seqretry(const seqlock_t *sl, unsigned start); 


static inline void write_seqlock(seqlock_t *sl); 
static inline void write_sequnlock(seqlock_t *sl); 
static inline void write_seqlock_irq(seqlock_t *sl); 
static inline void write_sequnlock_irq(seqlock_t *sl); 


static inline void read_seqlock_excl(seqlock_t *sl) 
static inline void read_sequnlock_excl(seqlock_t *s1l) 


and others. Before we move on to considering the implementation of this AP!, we must know 
that actually there are two types of readers. The first type of reader never blocks a writer 
process. In this case writer will not wait for readers. The second type of reader which can 


lock. In this case, the locking reader will block the writer as it will wait while reader will not 


release its lock. 


First of all let's consider the first type of readers. The read_seqbegin function begins a seq- 


read critical section. 


As we may see this function just returns value of the read_seqcount_begin function: 


static inline unsigned read_seqbegin(const seqlock_t *s1l) 


{ 


return read_seqcount_begin(&sl->seqcount ); 


In its turn the read_seqcount_begin function calls the raw_read_seqcount_begin function: 


static inline unsigned read_seqcount_begin(const seqcount_t *s) 


{ 


return raw_read_seqcount_begin(s); 


which just returns value of the sequential lock counter: 


static inline unsigned raw_read_seqcount(const seqcount_t *s) 


{ 
unsigned ret = READ_ONCE(s->sequence); 


smp_rmb(); 
return ret; 


After we have the initial value of the given sequential lock counter and did some stuff, we 

know from the previous paragraph of this function, that we need to compare it with the 

current value of the counter the same sequential lock before we will exit from the critical 

section. We can achieve this by the call of the read_segretry function. This function takes a 
sequential lock , Start value of the counter and through a chain of functions: 


static inline unsigned read_seqretry(const seqlock_t *sl, unsigned start) 


{ 


return read_seqcount_retry(&sl->seqcount, start); 


static inline int read_seqcount_retry(const seqcount_t *s, unsigned start) 
{ 

smp_rmb(); 

return __read_seqcount_retry(s, start); 


it calls the read_seqcount_retry function: 


static inline int __read_seqcount_retry(const seqcount_t *s, unsigned start) 


{ 


return unlikely(s->sequence != start); 


which just compares value of the counter of the given sequential lock with the initial value 
of this counter. If the initial value of the counter which is obtained from read_seqbegin( ) 
function is odd, this means that a writer was in the middle of updating the data when our 
reader began to act. In this case the value of the data can be in inconsistent state, so we 
need to try to read it again. 


This is a common pattern in the Linux kernel. For example, you may remember the jiffies 
concept from the first part of the timers and time management in the Linux kernel chapter. 
The sequential lock is used to obtain value of jiffies at x86 64 architecture: 


u64 get_jiffies_64(void) 
{ 
unsigned long seq; 
u64 ret; 
do { 
seq = read_seqbegin(&jiffies_lock); 
ret = jiffies_64; 


} while (read_seqretry(&jiffies_lock, seq)); 
return ret; 


Here we just read the value of the counter of the jiffies_lock sequential lock and then we 

write value of the jiffies_64 system variable to the ret . As here we may see do/while 

loop, the body of the loop will be executed at least one time. So, as the body of loop was 

executed, we read and compare the current value of the counter of the jiffies_lock with 

the initial value. If these values are not equal, execution of the loop will be repeated, else 
get_jiffies_64 will return its value in ret . 


We just saw the first type of readers which do not block writer and other readers. Let's 
consider second type. It does not update value of a sequential lock counter, but just locks 


spinlock : 


static inline void read_seqlock_excl(seqlock_t *sl) 


{ 
spin_lock(&sl->lock); 


So, no one reader or writer can't access protected data. When a reader finishes, the lock 
must be unlocked with the: 


static inline void read_sequnlock_excl(seqlock_t *sl) 
{ 
spin_unlock(&sl->lock); 


function. 


Now we know how sequential lock work for readers. Let's consider how does writer act 
when it wants to acquire a sequential lock to modify data. To acquire a sequential lock , 
writer should use write_seqlock function. If we look at the implementation of this function: 


static inline void write_seqlock(seqlock_t *s1l) 


{ 
spin_lock(&sl->lock); 
write_seqcount_begin(&sl->seqcount); 


We will see that it acquires spinlock to prevent access from other writers and calls the 
write_seqcount_begin function. This function just increments value of the sequential lock 
counter: 


static inline void raw_write_seqcou 9egin(seqcount_t *s) 


s->sequencet+; 


smp_wmb(); 


When a writer process will finish to modify data, the write_sequnlock function must be 
called to release a lock and give access to other writers or readers. Let's consider at the 
implementation of the write _sequnlock function. It looks pretty simple: 


static inline void write_sequnlock(seqlock_t *sl) 


{ 
write_seqcount_end(&sl->seqcount ); 
spin_unlock(&sl->lock); 


First of all it just calls write_seqcount_end function to increase value of the counter of the 
sequential lock again: 


static inline void raw_write_seqcount_end(seqcount_t *s) 
{ 

smp_wmb(); 

s->sequencet++; 


and in the end we just call the spin_unlock macro to give access for other readers or 
writers. 


That's all about sequential lock mechanism in the Linux kernel. Of course we did not 
consider full AP! of this mechanism in this part. But all other functions are based on these 
which we described here. For example, Linux kernel also provides some safe 
macros/functions to use sequential lock mechanism in interrupt handlers of softirq: 


write_seqclock_irq and write_sequnlock_irg : 


static inline void write_seqlock_irq(seqlock_t *sl) 
{ 
spin_lock_irq(&sl->lock); 
write_seqcount_begin(&sl->seqcount); 


} 
static inline void write sequnlock irq(seqlock t *sl) 
{ 
write_seqcount_end(&sl->seqcount ) ; 
spin_unlock_irq(&sl->lock); 
} 


As we may see, these functions differ only in the initialization of spinlock. They call 
spin_lock_irq and spin unlock_irq instead of spin_lock and spin_unlock . 


Or for example write_seqlock_irqsave and write _sequnlock_irgrestore functions which are 
the same but used spin_lock_irqsave and spin_unlock_irqsave macro to use in IRQ) 
handlers. 


That's all. 


Conclusion 


This is the end of the sixth part of the synchronization primitives chapter in the Linux kernel. 
In this part we met with new synchronization primitive which is called - sequential lock . 
From the theoretical side, this synchronization primitive very similar on a readers-writer lock 
synchronization primitive, but allows to avoid writer-starving issue. 


If you have questions or suggestions, feel free to ping me in twitter OxAX, drop me email or 
just create issue. 


Please note that English is not my first language and | am really sorry for any 
inconvenience. If you found any mistakes please send me PR to linux-insides. 
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Linux 内 核 内 存 管 理 


本 章 描 述 Linux 内 核 中 的 内 存 管理 。 在 本 章 中 你 会 看 到 一 系列 描述 Linux 内 核 内 存 管 理 框架 的 
不 同 部 分 的 帖子 。 


e 内 存 块 - 描述 早期 的 memblock 分 配器 。 
e 固定 映射 地 址 和 ioremap - 描述 国定 映射 的 地 址 和 早期 的 ioremap ° 
e kmemcheck - 第 三 部 分 描述 kmemcheck 工具 。 


内 核 内 存 管理 , 第 一 部 分 . 


内 存 管理 是 操作 系统 内 核 中 最 复杂 的 部 分 之 一 (我 认为 没有 之 一 ) 。 在 讲解 内 核 进入 点 之 前 的 准 
备 工作 时 ， 我 们 在 调用 start kernel 函数 前 停止 了 讲解 。 start kernel 函数 在 内 核 启 动 第 
一 个 init 进程 前 初始 化 了 所 有 的 内 核 特 性 (包括 那些 依赖 于 架构 的 特性 )。 你 也 许 还 记得 在 引 
导 时 建立 了 初期 页 表 、 识 别 页 表 和 固定 映射 页 表 ， 但 是 复杂 的 内 存 管理 部 分 还 没有 开始 工 

作 。 当 start_kernel 子 数 被 调用 时 ， 我 们 会 看 到 从 初期 内 存 管理 到 更 复杂 的 内 存 管理 数据 结 
构 和 技术 的 转变 。 为 了 更 好 地 理解 内 核 的 初始 化 过 程 ， 我 们 需要 对 这 些 技术 有 更 清晰 的 理 

解 。 本 章节 是 内 存 管理 框架 和 API 的 不 同 部 分 的 概述 ， 从 memblock 开始 。 


N Ak 


内 存 块 是 在 引导 初期 ， 泛 用 内 核 内 存 分 配器 还 没有 开始 工作 时 对 内 存 区 域 进行 管理 的 方法 之 
一 。 以 前 它 被 称 为 ” 远 辑 内 存 块 ， 但 是 内 核 接 纳 了 Yinghai Lu 提供 的 补丁 后 改名 为 ”memblock 

。 x86_64 架构 上 的 内 核 会 使 用 这 个 方法 。 我 们 已 经 在 讲解 内 核 进 入 点 之 前 的 准备 工作 时 遇 到 
过 了 它 。 现 在 是 时 候 对 它 更 加 熟悉 了 。 我 们 会 看 到 它 是 被 怎样 实现 的 。 


我 们 首先 会 学 习 memblock 的 数据 结构 。 以 下 所 有 的 数据 结构 都 在 include/linux/memblock.h 
头 文件 中 定义 。 


第 一 个 结构 体 的 名 字 就 叫做 memblock 。 它 的 定义 如 下 : 


struct memblock { 
bool bottom_up; 
phys_addr_t current_limit; 
struct memblock_type memory; --> array of memblock_region 
struct memblock_type reserved; --> array of memblock_region 
#ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP 
struct memblock_type physmem; 
#endif 
J; 


这 个 结构 体 包含 五 个 域 S 第 一 个 bottom_up 域 置 为 true 时 允许 内 存 以 自 底 向 上 模式 进行 分 
配 。 下 一 个 域 是 current_limit ° 这 个 域 描 述 了 内 存 块 的 尺寸 限制 。 接 下 来 的 三 个 域 描 述 了 
内 存 块 的 类 型 。 内 存 块 的 类 型 可 以 是 : 被 保留 ， 内 存 和 物理 内 存 (如 果 
CONFIG_HAVE_MEMBLOCK_PHYS_MAP 编译 配置 选项 被 开局)。 接 下 来 我 们 来 看 看 下 一 个 数据 结构 - 
memblock_type 。 让 我 们 来 看 看 它 的 定义 : 


struct memblock_type { 
unsigned long cnt; 
unsigned long max; 
phys_addr_t total_size; 
struct memblock_region *regions; 


}; 


这 个 结构 体 提 供 了 关于 内 存 类 型 的 信息 。 它 包含 了 描述 当前 内 存 块 中 内 存 区 域 的 数量 、 所 有 
内 存 区 域 的 大 小 、 内 存 区 域 的 已 分 配 数组 的 尺寸 和 指向 memblock_region 结构 体 数 据 的 指针 
的 域 。 memblock_region 结构 体 描述 了 一 个 内 存 区 域 ， 定 义 如 下 : 


struct memblock_region { 
phys_addr_t base; 
phys_addr_t size; 
unsigned long flags; 

#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP 
int nid; 

#endif 

J; 


memblock_region 提供 了 内 存 区 域 的 基 址 和 大 小 ” flags 域 可 以 是 : 


#define MEMBLOCK_ALLOC_ANYWHERE (~(phys_addr_t)0) 
#define MEMBLOCK_ALLOC_ACCESSIBLE 0 
#define MEMBLOCK_HOTPLUG 0x1 


同时 ， 如 果 CONFIG_HAVE_MEMBLOCK_NODE_MAP 编译 配置 选项 被 开启 ， memblock_region 结构 体 


也 提供 了 整数 域 - numa 节点 选择 器 。 


我 们 将 以 上 部 分 想象 为 如 下 示意 图 : 


memblock 
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这 三 个 结构 体 : memblock ， memblock_type 和 memblock_region 是 Memblock 的 主要 组 成 
部 分 。 现 在 我 们 可 以 进一步 了 解 Memblock 和 它 的 初始 化 过 程 了 。 


内 存 块 初始 化 


所 有 memblock 的 API 48 include/linux/memblock.h 头 文 件 中 描述 , 所 有 函数 的 实现 都 在 
mm/memblock.c 源码 中 。 首 先 我 们 来 看 一 下 源码 的 开头 部 分 和 memblock 结构 体 的 初始 化 
ve, o 


struct memblock memblock __initdata_memblock = { 


.memory.regions memblock_memory_init_regions, 


.memory.cnt =a aly 

. memor y . max = INIT_MEMBLOCK_REGIONS, 
„reserved. regions = memblock_reserved_init_regions, 
.reserved.cnt = 1, 

. reserved .max = INIT_MEMBLOCK_REGIONS, 


#ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP 


.physmem. regions = memblock_physmem_init_regions, 
. physmem. cnt zoly 
. physmem.max = INIT_PHYSMEM_REGIONS, 
#endif 
.bottom_up = false, 
.current_limit = MEMBLOCK_ALLOC_ANYWHERE, 
J; 


在 这 里 我 们 可 以 看 到 memblock 结构 体 的 同名 变量 的 初始 化 。 首 先 请 注意 
_ initdata_memblock 。 这 个 宏 的 定义 就 像 这 样 : 


#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK 

#define __init_memblock _ meminit 

#define __initdata_memblock __meminitdata 
#else 

#define __init_memblock 

#define __initdata_memblock 
#endif 


你 会 发 现 这 个 宏 依 赖 于 CONFIG_ARCH DISCARD MEMBLOCK ° 如果 这 个 编译 配置 选项 开启 ， 内 存 
块 的 代码 会 被 放置 在 .init 段 ， 这 样 它 就 会 在 内 核 引 导 完 毕 后 被 释放 掉 。 


接 下 来 我 们 可 以 看 看 memblock_type memory  ， memblock_type reserved 和 memblock_type 
physmem 域 的 初始 化 。 在 这 里 我 们 只 对 memblock_type.regions 的 初始 化 过 程 感 兴趣 ， 请 注意 
每 一 个 memblock_type 域 都 是 memblock_region 的 数组 初始 化 的 : 


static struct memblock_region memblock_memory_init_regions[INIT_MEMBLOCK_REGIONS] _ in 
itdata_memblock; 

static struct memblock_region memblock_reserved_init_regions[INIT_MEMBLOCK_REGIONS] __ 
initdata_memblock; 

#ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP 

static struct memblock_region memblock_physmem_init_regions[INIT_PHYSMEM_REGIONS] _ in 
itdata_memblock; 

#endif 


每 个 数组 包含 了 128 个 内 存 区 域 。 我 们 可 以 在 INIT_MEMBLOCK_REGIONS 宏 定 义 中 看 到 它 : 


#define INIT_MEMBLOCK_REGIONS 128 


请 注意 所 有 的 数组 定义 中 也 用 到 了 在 memblock 中 使 用 过 的 — initdata_memblock È (w R & 
掉 了 就 翻 到 上 面 重 温 一 下 ) 。 


最 后 两 个 域 描 述 了 bottom_up 分 配 是 否 被 开启 以 及 当前 内 存 块 的 限制 : 


#define MEMBLOCK_ALLOC_ANYWHERE (~(phys_addr_t)0) 


这 个 限制 是 9xffffffffffffffff . 


On this step the initialization of the memblock structure has been finished and we can look 
on the Memblock API. 到 此 为 止 memblock 结构 体 的 初始 化 就 结束 了 ， 我 们 可 以 开始 看 内 存 
块 相关 API 了 。 


内 存 块 应 用 程序 接口 


我 们 已 经 结束 了 memblock 结构 体 的 初始 化 讲解 ， 现 在 我 们 要 开始 看 内 存 块 API 和 它 的 实现 
了 。 就 像 我 上 面 说 过 的 ， 所 有 memblock 的 实现 都 在 mm/memblock.c 中 。 为 了 理解 
memblock 是 怎样 被 实现 和 工作 的 ， 让 我 们 先 看 看 它 的 用 法 。 内 核 中 有 很 多 地 方 用 到 了 内 存 
块 。 举 个 例子 ， 我 们 来 看 看 arch/x86/kernel/e820.c 中 的 memblock_x86 fill 函数 。 这 个 函数 
使 用 了 e820 提供 的 内 存 映射 并 使 用 memblock_add 函数 在 memblock 中 添加 了 内 核 保留 的 内 
存 区 域 。 既 然 我 们 首先 遇 到 了 memblock_add HA > HERA MC AA HARPS o 


这 个 函数 获取 了 物理 基 址 和 内 存 区 域 的 大 小 并 把 它们 加 到 了 memblock 中 。 memblock_add % 
数 本 身 没 有 做 任何 特殊 的 事情 ， 它 只 是 调用 了 


memblock_add_range(&memblock.memory, base, size, MAX_NUMNODES, 0); 


函数 。 我 们 将 内 存 块 类 型 - memory ， 内 存 基 址 和 内 存 区 域 大 小 ， 节 点 的 最 大 数目 和 标志 传 进 
去 。 如 果 CONFIG NODES_SHIFT 没有 被 设置 ， 最 大 节点 数目 就 是 1， 否则 是 1 << 
CONFIG_NODES_SHIFT ° memblock_add_range 函数 将 新 的 内 存 区 域 加 到 了 内 存 块 中 ， 它 首先 检查 
传 入 内 存 区 域 的 大 小 ， 如 果 是 0 就 直接 返回 。 然 后 ， 这 个 函数 会 用 memblock_type 来 检查 
memblock 中 的 内 存 区 域 是 否 存 在 。 如 果 不 存 在 ， 我 们 就 简单 地 用 给 定 的 值 填 充 一 个 新 的 
memory_region 然后 返回 (我 们 已 经 在 对 内 核 内 存 管理 框架 的 初 览 中 看 到 了 它 的 实现 )。 如 果 
memblock_type 不 为 空 ， 我 们 就 会 使 用 提供 的 memblock_type 将 新 的 内 存 区 域 加 到 


memblock 中 S 


首先 ， 我 们 获取 了 内 存 区 域 的 结束 点 : 


phys_addr_t end = base + memblock_cap_size(base, &size); 


memblock_cap_size 调整 了 size 使 base + size 不 会 溢出 。 它 的 实现 非常 简单 : 


static inline phys_addr_t memblock_cap_size(phys_addr_t base, phys_addr_t *size) 


{ 
return *size = min(*size, (phys_addr_t)ULLONG_MAX - base); 


memblock_cap_size 返回 了 提供 的 值 与 ULLONG_MAX - base 中 的 较 小 值 作为 新 的 尺寸 Q 


之 后 ， 我 们 获得 了 新 的 内 存 区 域 的 结束 地 址 ， memblock_add_range 会 检查 与 已 加 入 内 存 区 域 
是 否 重 司 以 及 能 否 合 并 。 将 新 的 内 存 区 域 插入 memblock 包含 两 步 : 
。 将 新 内 存 区 域 的 不 重重 部 分 作为 单独 的 区 域 加 入 ; 
。 合并 所 有 相 接 的 区 域 。 
我 们 会 迭代 所 有 的 已 存储 内 存 区 域 来 检查 是 否 与 新 区 域 重 枉 : 
for (i = 0; i < type->cnt; i++) { 
struct memblock_region *rgn = &type->regions[i]; 


phys_addr_t rbase = rgn->base; 
phys_addr_t rend = rbase + rgn->size; 


if (rbase >= end) 


break; 
if (rend <= base) 
continue; 


如 果 新 的 内 存 区 域 不 与 已 有 区 域 重 王 ， 直 接 插入 。 和 否则 我 们 会 检查 这 个 新 内 存 区 域 是 否 合适 
并 调用 memblock_double_array žr: 


while (type->cnt + nr_new > type->max) 


if (memblock_double_array(type, obase, size) < 0) 
return -ENOMEM; 
insert = true; 


goto repeat; 


memblock_double_array 会 将 提供 的 区 域 数 组 长 度 加 倍 。 然 后 我 们 会 将 insert BA true ， 
接着 跳 转 到 repeat 标签 。 第 二 步 ， 我们 会 从 repeat 标签 开始 ， 和 迭代 同样 的 循环 然后 使 用 
memblock_insert_region 函数 将 当 前 内 存 区 域 插入 内 存 块 : 


if (base < end) { 
nr_new++; 


if (insert) 


memblock_insert_region(type, i, base, end - base, 
nid, flags); 


我 们 在 第 一 步 将 insert 置 为 true ， 现 在 memblock_insert_region 会 检查 这 个 标 
志 。 memblock_insert_region 的 实现 与 我 们 将 新 区 域 插 入 空 memblock_type 的 实现 (看 上 面 ) 
几乎 相同 。 这 个 函数 会 获取 最 后 一 个 内 存 区 域 : 


struct memblock_region *rgn = &type->regions[idx]; 


然后 用 memmove 拷贝 这 部 分 内 存 : 


memmove(rgn + 1, rgn, (type->cnt - idx) * sizeof(*rgn)); 


之 后 我 们 会 填充 memblock_region 域 ， 然 后 增长 memblock_type 的 尺寸 。 在 函数 执行 的 结 
R ” memblock_add_range 会 调用 memblock_merge_regions 来 在 第 二 步 合 并 相 邻 可 合并 的 内 存 
区 域 。 


还 有 第 二 种 情况 ， 新 的 内 存 区 域 与 已 储存 区 域 完全 重合 。 比 如 memblock 中 已 经 有 了 


region1t 


0 0x1000 


regioni 


现在 我 们 想 在 memblock 中 添加 region2 ， 它 的 基 址 和 尺寸 如 下 : 


0x100 0x2000 
Ec T E A + 
| | 
| | 
| region2 | 
| | 
| | 
a ee ee + 


在 这 种 情况 下 ， 新 内 存 区 域 的 基 址 会 被 像 下 面 这 样 设置 : 


base = min(rend, end); 


所 以 在 我 们 设置 的 这 种 场景 中 ， 它 会 被 设置 为 ”gx16996 。 然 后 我 们 会 在 第 二 步 中 将 这 个 区 域 
插入 : 


if (base < end) { 
nr_new++; 
if (insert) 
memblock_insert_region(type, i, base, end - base, nid, flags); 


在 这 种 情况 下 我 们 会 插入 overlapping portion (我 们 之 插入 地 址 高 的 部 分 ， 因 为 低地 址 部 分 
已 经 被 包 SHEE RRET) ， 然 后 会 使 用 memblock _merge_regions 合并 剩 余部 分 个 区 域 。 就 像 
我 上 文中 所 说 的 那样 ， 这 个 函数 会 合并 相 邻 的 可 合并 区 域 。 它 会 从 给 定 的 _memblock _type a 
历 所 有 的 内 存 区 域 取出 两 个 相 邻 区 域 - type->regions[i] 和 type->regions[i + 1] > 并 检 
查 他 们 是 否 拥 有 同样 的 标志 ， 是 否 属于 同一 个 节点 ， 第 一 个 区 域 的 末尾 地 址 是 否 与 第 二 个 区 

域 的 基地 址 相同 。 


while (i < type->cnt - 1) { 
struct memblock_region *this = &type->regions[i]; 
struct memblock_region *next = &type->regions[i + 1]; 
if (this->base + this->size != next->base | | 
memblock_get_region_node(this) != 
memblock_get_region_node(next) | | 
this->flags != next->flags) { 
BUG_ON(this->base + this->size > next->base); 
i++; 


continue; 


如 果 上 面 所 说 的 这 些 条 件 全 部 符合 ， 我 们 就 会 更 新 第 一 个 区 域 的 长 度 ， 将 第 二 个 区 域 的 长 度 
加 上 去 。 


this->size += next->size; 


我 们 在 更 新 第 一 个 区 域 的 长 度 同 时 ， 会 使 用 memmove 将 后 面 的 所 有 区 域 向 前 移动 一 个 下 标 。 


memmove(next, next + 1, (type->cnt - (i + 2)) * sizeof(*next)); 


然后 将 memblock_type 中 内 存 区 域 的 数量 减 一 : 


type->cnt--; 


经 过 这 些 操作 后 我 们 就 成 功 地 将 两 个 内 存 区 域 合并 了 : 


0 0x2000 
ce E E + 
| | 
| | 
| regioni | 
| | 
| | 
rs + 


这 就 是 memblock_add_range 函数 的 工作 原理 和 执行 过 程 。 


同样 还 有 一 个 memblock_reserve ‘3x47 memblock_add 几乎 完成 同样 的 工作 ， 只 有 一 点 不 
E] : memblock_reserve 将 memblock_type.reserved 而 不 是 memblock_type.memory 储存 到 内 


存 块 中 。 


当然 这 不 是 全 部 的 API。 内 存 块 不 仅 提 供 了 添加 memory 和 reserved 内 存 区 域 ， 还 提供 
p 


memblock remove - 从 内 存 块 中 移 除 内 存 区 域 ; 
memblock_find_in_range - 寻找 给 定 范围 内 的 未 使 用 区 域 ; 
memblock_free - 释放 内 中 的 内 存 区 域 ; 

e for_each_mem_range - 迭代 遍历 内 存 块 区 域 。 


获取 内 存 区 域 的 相关 信息 


内 存 块 还 提供 了 获取 memblock 中 已 分 配 内 存 区 域 信息 的 APIl。 和 包括 两 部 分 : 


e get_allocated_memblock_memory_regions_info- 获取 有 关内 存 区 域 的 信息 ; 
e get_allocated_memblock_reserved_regions_info - 获取 有 关 保 留 区 域 的 信息 。 


Ye 


些 函 数 的 实 现 都 很 简 单 。 以 get_allocated memblock_reserved_regions_info A: 


phys_addr_t init_memblock get_allocated_memblock 





reserved_regions_info( 
phys_addr_t *addr) 
{ 
If (memblock.reserved.regions == memblock_reserved_init_regions) 
return o; 
*addr = __pa(memblock.reserved.regions); 
return PAGE_ALIGN(sizeof(struct memblock_region) * 
memblock.reserved.max); 
} 


这 个 函数 首先 会 检查 memblock 是 否 包 含 保留 内 存 区 域 。 如 果 否 ， 就 直接 返回 0 o a 
将 保留 内 存 区 域 的 物理 地 址 写 到 传 入 的 数组 中 ， 然 后 返回 已 分 配 数组 的 对 齐 后 尺寸 。 注 意 
数 使 用 PAGE_ALIGN 这 个 宏 实 现 对 齐 。 实 际 上 这 个 宏 依赖 于 页 的 尺寸 : 


主意 函 


#define PAGE_ALIGN(addr) ALIGN(addr, PAGE_SIZE) 


get_allocated_memblock_memory_regions_info 3H HAY 实现 是 基本 一 样 的 只 有 一 处 不 
同 ， get_allocated_memblock_memory_regions_info 使 用 memblock_type.memory 而 不 是 


memblock_type.reserved ° 


内 存 块 的 相关 除 错 技术 


在 内 存 块 的 实现 中 有 许多 对 memblock_dbg 的 调用 。 如 果 在 内 核 行 中 传 入 
memblock=debug 选项 ， 这 个 函数 就 会 被 调用 。 实 际 上 memblock_dbg printk 的 一 个 拓展 


= 


B+ 


#define memblock_dbg(fmt, ...) \ 
if (memblock_debug) printk(KERN_INFO pr_fmt(fmt), ## VA ARGS ) 


比如 你 可 以 在 memblock_reserve 函数 中 看 到 对 这 个 宏 的 调用 : 


memblock_dbg("memblock_reserve: [%#01611x-%#01611x] flags %#021x %pF\n", 
(unsigned long long)base, 
(unsigned long long)base + size - 1, 
flags, (void *)_RET_IP_); 


然后 你 将 看 到 类 似 下 图 的 画面 


Kernel command line: root=/dev/sdb earlyprintk=ttySO loglevel=7 debug rdinit=/sbin/init root=/dev/ram memblock=debug 
memblock_virt_alloc_try_nid_nopanic: 32768 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 alloc_large_system_hash+0x144/0x228 
memblock_reserve: [0x0000023ff38e00-0x0000023ff40dff] flags 0x0 memblock_virt_alloc_internal+0xfd/0x13f 

PID hash table entries: 4096 (order: 3, 32768 bytes) 

memblock_virt_alloc_try_nid_nopanic: 67108864 bytes align=0x1000 nid=-1 from=0x® max_addr=OxfffffffF swiotlb_init+0x4c/Oxad 
memblock_reserve: [0x000000bbfe0000-0x000009bffdffff] flags 9x9 memblock_virt_alloc_internal+0xfd/0x13f 


memblock_virt_alloc_try_nid_nopanic: 32768 bytes align=0x1000 nid=-1 from=0x0 max_addr=Oxffffffff swiotlb_init_with_tbl1+0x69/0x147 
memblock_reserve: [0x000000bbfd8000-Ox900000bbfdffff] flags 0x0 memblock_virt_alloc_internal+0xfd/0x13f 
memblock_virt_alloc_try_nid: 131072 bytes align=0x1000 nid=-1 from=0x® max_addr=0x® swiotlb_init_with_tbl+0xb9/0x147 
memblock_reserve: [0x0000023ff18000-0x0000023ff37fFFF] flags 9x9 memblock_virt_alloc_internal+0xfd/0x13f 
memblock_virt_alloc_try_nid: 262144 bytes align=0x1000 nid=-1 from=0x0 max_addr=0x0 swiotlb_init_with_tbl+0xe8/0x147 
memblock_reserve: [0x0000023fed8000-0x0000023ff17fFFF] flags 0x0 memblock_virt_alloc_internal+0xfd/0x13f 





内 存 块 技术 也 支持 debugfs 。 如 果 你 不 是 在 x86 架构 下 运行 内 核 ， 你 可 以 访问 : 


e /sys/kernel/debug/memblock/memory 
e /sys/kernel/debug/memblock/reserved 
e /sys/kernel/debug/memblock/physmem 


来 获取 memblock 内 容 的 核心 转 储 信息 。 


结束 语 


讲解 内 核 内 存 管理 的 第 一 部 分 到 此 结束 ， 如 果 你 有 任何 的 问题 或 者 建议 ， 你 可 以 直接 发 消息 
给 我 twitter， 也 可 以 给 我 发 邮件 或 是 直接 创建 一 个 issue。 


英文 不 是 我 的 母语 。 如 果 你 发 现 我 的 英文 描述 有 任何 问题 ， 请 提交 一 个 PR 到 linux-insides. 


相关 连接 


e e820 
e numa 
e debugfs 


内 存 块 
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内 核 内 存 管 理 . 第 二 部 分 . 


定 映射 地 址 和 输入 输出 重 映射 


固定 映射 地 址 是 一 组 特殊 的 编译 时 确定 的 地 址 ， 它 们 与 物理 地 址 不 一 定 具 有 减 

START_KERNEL_map 的 线性 映射 关系 。 每 一 个 国定 映射 的 地 址 都 会 映射 到 一 个 内 存 页 ， 内 核 
会 像 指针 一 样 使 用 它们 ， 但 是 绝 不 会 修改 它们 的 地 址 。 这 是 这 种 地 址 的 主要 特点 。 就 像 注释 
所 说 的 那样 ，“ 在 编译 期 就 获得 一 个 常量 地 址 ， 只 有 在 引导 阶段 才 会 被 设 定 上 物理 地 址 。” 你 在 
本 书 的 前 面部 分 可 以 看 到 ， 我 们 已 经 设 定 了 level2 fixmap_pgt 





NEXT_PAGE(level2_fixmap_pgt) 
fan 506,8,0 
. quad level1_fixmap_pgt - START_KERNEL_map + _PAGE_TABLE 
riik 5,8,0 





NEXT_PAGE(level1_fixmap_pgt) 
Pfeil 512,8,0 


就 像 我 们 看 到 的 ， level2_fixmap_pgt 紧 挨 着 level2_kernel_pgt 保存 了 内 核 的 
code+data+bss 段 。 每 一 个 国定 映射 的 地 址 都 由 一 个 整数 下 标 表 示 ， 这 些 整数 下 标 在 
arch/x86/include/asm/fixmap.h 的 fixed_addresses 枚 举 类 型 中 定义 。 比 如 ， 它 包含 

了 VSYSCALL_PAGE 的 入 口 - 如 果 合 法 的 vsyscall 页 模拟 机 制 被 开启 ， 或 是 启用 了 本 地 apic 的 


FIX_APIC_BASE 选项 等 等 。 在 虚拟 内 存 中 ， 固 定 映 射 区 域 被 放置 在 模块 区 域 中 : 


Poessasasscs TEREE TE 生生 + 

| | | | | 

|kernel text] kernel | | vsyscalls | 

| mapping | text | Modules | fix-mapped | 

|from phys 0] data | | addresses | 

| | | | | 

Moccan ooann 本 二 下 十 
START_KERNEL_map START_KERNEL MODULES_VADDR Oxffffffffffffffff 





基 虚 拟 地 址 和 固定 映射 区 域 的 尺寸 使 用 以 下 两 个 宏 表示 : 


#define FIXADDR_SIZE (__end_of_permanent_fixed_addresses << PAGE_SHIFT) 
#define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE) 


在 这 里 __end_of_permanent_fixed_addresses 是 fixed_addresses KEP 的 一 个 元 素 ? 如 我 上 
文 所 说 : 每 一 个 固定 映射 地 址 都 由 一 个 定义 在 fixed_addresses 中 的 整数 下 标 表 

示 。 PAGE_SHIFT 决定 了 页 的 大 小 。 比 如 ， 我 们 可 以 使 用 1 << PAGE_SHIFT 来 获取 一 页 的 大 
小 。 在 我 们 的 场景 下 需要 获取 固定 映射 区 域 的 尺寸 ， 而 不 仅仅 是 一 页 的 大 小 ， 这 就 是 我 们 使 
用 __end_of_permanent_fixed_addresses 来 获取 固定 映射 区 域 尺 寸 的 原因 。 在 我 的 系统 中 这 个 
值 可 能 略 大 于 536 KB 。 在 你 的 系统 上 这 个 值 可 能 会 不 同 ， 因 为 这 个 值 取决 于 国定 映射 地 址 
的 数目 ， 而 这 个 数目 又 取决 于 内 核 的 配置 。 


The second FIXADDR_START macro just substracts fix-mapped area size from the last 
address of the fix-mapped area to get its base virtual address. FIxXADDR ToP is a rounded up 
address from the base address of the vsyscall space: 第 二 个 FIXADDR_START 宏 只 是 从 固定 
映射 区 域 的 末 地 址 减 去 了 固定 映射 区 域 的 尺寸 ， 这 样 就 可 以 获得 它 的 基 虚 拟 地 址 。 

FIXADDR_TOP 是 一 个 从 vsyscall 室 间 的 基 址 取 整 产生 的 地 址 : 


#define FIXADDR_TOP (round_up(VSYSCALL_ADDR + PAGE_SIZE, 1<<PMD_SHIFT) - PAGE_SIZE) 


Eo [M 


fixed_addresses 枚 举 量 被 fixtovirt HAMT ir M TAPE DHE BPHANKLM 
很 简单 : 


static __always_inline unsigned long fix_to_virt(const unsigned int idx) 
{ 

BUILD_BUG_ON(idx >= end_of_fixed_addresses) ; 

return __fix_to_virt(idx); 





首先 它 调用 BUILD_BuG_ON 宏 检 查 了 给 定 的 fixed_addresses 枚 举 量 不 大 于 等 于 


end_of_fixed_addresses ， 然后 返回 __fix_to_virt 宏 的 运算 结果 : 





#define _ fix to virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT)) 


在 这 里 我 们 用 PAGE_SHIFT 左 移 了 给 定 的 固定 映射 地 址 下 标 ， 就 像 我 上 文 所 述 它 决定 了 页 的 
地 址 ， 然 后 将 FIXADDR_TOP 减 去 这 个 值 ， FIXADDR_TOP 是 固定 映射 区 域 的 最 高 地 址 。 以 下 是 
从 虚拟 地 址 获取 对 应 固定 映射 地 址 的 转换 函数 


static inline unsigned long virt_to_fix(const unsigned long vaddr) 
{ 
BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START); 
return __virt_to_fix(vaddr); 


virt_to fix 以 虚拟 地 址 为 参数 ， 检 查 了 这 个 地 址 是 否 位 于 FIXADDR_START 和 FIXADDR_TOP 
之 间 ， 然 后 调用 ”virt to fix ， 这 个 宏 实 


#define _ virt_ to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT) 


一 个 PFN 是 一 块 页 大 小 物理 内 存 的 下 标 。 一 个 物理 地 址 的 PFN 可 以 简单 地 定义 为 
(page_phys_addr >> PAGE_SHIFT) : 


__virt_to_fix 会 清空 给 定 地 址 的 前 12 位 ， 然 后 用 国定 映射 区 域 的 末 地 址 ( FIXADDR_TOP ) 减 
去 它 并 右 移 PAGE_SHIFT PP 12 位 。 让 我 们 来 解释 它 的 工作 原理 。 就 像 我 已 经 写 的 那样 ， 这 个 
宏 会 使 用 x & PAGE_MASK 来 清空 前 12 位 。 然 后 我 们 用 FIXADDR_TOP 减 去 它 ， 就 会 得 到 
FIXADDR_TOP 的 后 12 位 。 我 们 知道 虚拟 地 址 的 前 12 位 代表 这 个 页 的 偏 移 量 ， 当 我 们 右 移 
PAGE_SHIFT 后 就 会 得 到 page frame number ， 即 虚拟 地 址 的 所 有 位 ， 包 括 最 开始 的 12 个 偏 
移 位 。 固 定 映射 地 址 在 内 核 中 多 处 使 用 。 it 描述 符 保 存在 这 里 ， 英 特 尔 可 信赖 执行 技术 
UUID 储存 在 固定 映射 区 域 ， 以 FIX_TBOoT_BASE 下 标 开始 。 另 外 ，Xen 引导 映射 等 也 储存 在 
这 个 区 域 。 我 们 已 经 在 内 核 初始 化 的 第 五 部 分 看 到 了 一 部 分 关于 固定 映射 地 址 的 知识 。 接 下 
来 让 我 们 看 看 什么 是 ioremap ， 看 看 它 是 怎样 实现 的 ， 与 固定 映射 地 址 又 有 什么 关系 呢 ? 


输入 输出 重 映射 


内 核 提 供 了 许多 不 同 的 内 存 管理 原 语 。 现 在 我 们 将 要 接触 I/0 内 存 。 每 一 个 设备 都 通过 读 写 
它 的 寄存 器 来 控制 。 比 如 ， 驱 动 可 以 通过 向 它 的 寄存 器 中 写 来 打开 或 关闭 设备 ， 也 可 以 通过 
读 它 的 寄存 器 来 获取 设备 状态 。 除 了 寄存 器 之 外 ， 许 多 设备 都 拥有 一 块 可 供 驱 动 读 写 的 缓冲 
区 。 如 我 们 所 知 ， 现 在 有 两 种 方法 来 访问 设备 的 寄存 器 和 数据 缓冲 区 : 


e 通过 |/ 端口; 
e 将 所 有 寄存 器 映射 到 内 存 地 址 空间 ; 


第 一 种 情况 ， 设 备 的 所 有 控制 寄存 器 都 具有 一 个 输入 输出 端口 号 。 该 设备 的 驱动 可 以 用 in 
和 out 指令 来 从 端口 中 读 写 。 你 可 以 通过 访问 /proc/ioports 来 获取 设备 当前 的 IO 端口 


iza 


F o 


$ cat /proc/ioports 
Q000-Ocf7 : PCI Bus 0000:00 
0000-001f : dmat 
0020-0021 : pict 
0040-0043 : timer0 
0050-0053 : timer1 
0060-0060 : keyboard 
0064-0064 : keyboard 
0070-0077 : rtcO 
0080-008f : dma page reg 
00a0-00a1 : pic2 
00c0-00df : dma2 
oofo-ooff : fpu 
00f0-00f0 : PNPOCO4:00 
03c0-03df : vesafb 
03f8-03ff : serial 
04d0-04d1 : pnp 00:06 
0800-087f : pnp 00:01 
0a00-0a0f : pnp 00:04 
0a20-0a2f : pnp 00:04 
0a30-0a3f : pnp 00:04 
Ocf8-Ocff : PCI confi 
0d00-ffff : PCI Bus 0000:00 


/proc/ioports 提供 了 驱动 使 用 W/O 端口 的 内 存 区 域 地 址 。 所 有 的 这 些 内 存 区 域 ， 比 如 oooo- 
ocf7 ， 都 是 使 用 include/linux/ioport.h 头 文件 中 的 request_region 来 声明 的 。 实 际 上 
request_region 是 一 个 宏 ， 它 的 定义 如 下 : 


#define request_region(start,n, name) __request_region(&ioport_resource, (start), (n) 
, (name), ©) 


正如 我 们 所 看 见 的 ， 它 有 三 个 参数 : 


e start - 区域 的 起 点 ; 
e n -区域 的 长 度 ; 
e name -区 域 需求 者 的 名 字 。 


request_region 分 配 I/O 端口 区 域 。 通 常 在 request_region 之 前 会 调用 check_region 来 检 
查 传 入 的 地 址 区 间 是 否 可 用 ， 然 后 release_region 会 释放 这 个 内 存 区 域 ° request_region 
返回 指向 resource 结构 体 的 指针 。 resource 结构 体 是 对 系统 资源 的 树 状 子 集 的 抽象 。 我 
们 已 经 在 内 核 初始 化 的 第 五 部 分 见 到 过 它 了 ， 它 的 定义 是 这 样 的 : 


struct resource { 
resource_size_t start; 
resource_size_t end; 
const char *name; 
unsigned long flags; 
struct resource *parent, *sibling, *child; 


}; 


它 包 含 起 止 地 址 、 名 字 等 等 ? 每 一 个 resource 结构 体 包含 一 个 指向 parent `œ slibling 和 
child 资源 的 指针 。 它 有 父 节点 和 子 节点 ， 这 就 意味 着 每 一 个 资源 的 子 集 都 有 一 个 根 节点 。 
比如 ， 对 |/ 〇 端口 来 说 有 一 个 ioport_resource 结构 体 : 


struct resource ioport_resource = { 


.name = UPET TOS 
.Start = 0, 
„end = IO_SPACE_LIMIT, 


.flags = IORESOURCE_IO, 


J; 
EXPORT_SYMBOL(ioport_resource); 


或 者 对 iomem 来 说 ， 有 一 个 iomem_resource 结构 体 : 


struct resource iomem_resource = { 


.name = "PCI mem", 
.Start = 0, 

.end = -1, 

.flags = IORESOURCE_MEM, 


J; 


就 像 我 所 写 的 ， request region 用 于 注册 1/O 端口 区 域 ， 这 个 宏 用 于 内 核 中 的 许多 地 方 。 上 比 
如 让 我 们 来 看 看 drivers/char/rtc.c。 这 个 源 文 件 提 供 了 内 核 中 的 实时 时 钟 接口 。 与 其 他 内 核 模 
块 一 样 ， rtc 模块 包含 一 个 module init 定义 : 


module_init(rtc_ init); 


在 这 里 rtc_init 是 rte 模块 的 初始 化 函数 。 这 个 函数 也 定义 在 rtc.c 文件 中 。 在 
rtc_init 函数 中 我 们 可 以 看 到 许多 对 rtc_request_region 函数 的 调用 ， 实 际 上 这 是 


request_region 的 包装 : 


r = rtc_request_region(RTC_IO_EXTENT); 


rtc_request_region 中 调用 J: 


r = request_region(RTC_PORT(0), size, "rtc"); 


在 这 里 RTC_TO_EXTENT 是 一 个 内 存 区 域 的 尺寸 ， 在 这 里 是 gx8 ， "rtc" 是 区 域 的 名 


> RTC PORT 是 : 


#define RTC_PORT(x) (0x70 + (x)) 


所 以 使 用 request_region(RTC_PORT(@), size, "rtc") 我 们 注册 了 一 个 内 存 区 域 ， 以 0x70 
开始 ， 大 小 为 oxs 。 让 我 们 看 看 /proc/ioports : 


~$ sudo cat /proc/ioports | grep rtc 
0070-0077 : rtco 


看 ， 我 们 可 以 获取 了 它 的 信息 。 这 就 是 端口 。 第 二 种 途径 是 使 用 IO 内 存 。 就 像 我 上 面 写 的 ， 
这 是 将 设备 的 控制 寄存 器 和 内 存 映射 到 内 存 地 址 空间 中 。I/O 内 存 是 一 组 由 设备 通过 总 线 提 供 
给 CPU 的 相 邻 的 地 址 。 所 有 的 WO 映射 地 址 都 不 能 由 内 核 直接 访问 。 有 一 个 ioremap 函数 
用 来 将 总 线 上 的 物理 地 址 转化 为 内 核 的 虚拟 地 址 ， 或 者 说 ， ioremap 映射 了 1/O 物理 地 址 来 
让 他 们 能 够 在 内 核 中 使 用 。 这 个 函数 有 两 个 参数 : 


© 内 存 区 域 的 开始 ; 
© 内 存 区 域 的 结 


VO 内 存 映 射 API 提供 了 用 来 检查 、 请 求 与 释放 内 存 区 域 的 函数 ， 就 像 1/O 34.0 API 一 样 。 这 
里 有 三 个 函数 : 


® request_mem_region 
© release_mem_region 


@ check_mem_region 


~$ sudo cat /proc/iomem 


be826000 -be82cffFf 
be82d000-bf744fff : 
bf745000-bfff4fff : 
bfff5000-dc041f fF : 
dc042000-dcOd2ffFf : 
dc0d3000-dc1i38ffFf : 
dc139000-dc27dffFf 
dc27e000-deffefff : 
defff000-deffffff : 
df000000-dfffffff : 
e0000000-feafffff : 


: ACPI Non-volatile Storage 


System RAM 
reserved 
System RAM 
reserved 
System RAM 


: ACPI Non-volatile Storage 


reserved 

System RAM 

RAM buffer 

PCI Bus 0000:00 


e0000000-effffffF : PCI Bus 0000:01 


e0000000-efffffff : 


0000:01:00.0 


f7c00000-f7cffffFf : PCI Bus 0000:06 


f7c00000-f7coffff : 
f7c10000-f7c101fF : 


0000:06:00.0 
0000:06:00.0 
f7c10000-f7c101fF : 


ahci 


f7d00000-f7dfffff : PCI Bus 0000:03 


f7d00000-f7d3ffff : 


这 些 地 址 中 的 一 部 分 源 于 对 e826_reserve_resources 函数 的 调用 。 我 们 可 以 在 
arch/x86/kernel/setup.c 中 找到 对 这 个 函数 的 调用 ， 这 个 函数 本 身 定义 在 
arch/x86/kernel/e820.c 中 。 这 个 函数 遍历 了 e820 的 映射 然后 将 内 存 区 域 插入 了 根 iomen 
构 体 中 。 所 有 具有 以 下 类 型 的 e826 内 存 区 域 都 会 被 插入 到 iomem 结构 体 中 : 


static inline const char *e820_type_to_string(int e820_type) 


{ 
switch (e820_type) { 
case E820_RESERVED_KERN: 
case E820_RAM: return "System RAM"; 
case E820_ACPI: return "ACPI Tables"; 
case E820_NVS: return "ACPI Non-volatile Storage"; 
case E820_UNUSABLE: return "Unusable memory"; 
default: return "reserved"; 
} 
} 


0000:03:00.0 
f7d00000-f7d3ffff : 


alx 


我 们 可 以 在 /proc/iomem 中 看 到 它们 。 


gt 
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现在 让 我 们 尝试 着 理解 ioremap 是 如 何 工 作 的 。 我 们 已 经 了 解 了 一 部 分 ioremap 的 知识 ， 
我 们 在 内 核 初始 化 的 第 五 部 分 见 过 它 。 如 果 你 读 了 那个 章节 ， 你 就 会 记得 
arch/x86/mm/ioremap.c 文件 中 对 early_ioremap_init 函数 的 调用 。 对 ioremap 的 初始 化 分 
为 两 个 部 分 : 有 一 部 分 在 我 们 正常 使 用 ioremap 之 前 ， 但 是 要 首先 进行 vmalloc 的 初始 化 
并 调用 paging init 才能 进行 正常 的 ioremap 调用 。 我 们 现在 还 不 了 解 vmalloc 的 知识 ， 
先 看 看 第 一 部 分 的 初始 化 。 首 先 early_ioremap_init 会 检查 固 定 映射 是 否 与 页 中 部 目录 对 

齐 : 


外 


BUILD_BUG_ON( (fix_to_virt(0) + PAGE_SIZE) & ((1 << PMD_SHIFT) - 1)); 


多 关于 BUILD_BUG_ON 的 内 容 你 可 以 在 内 核 初始 化 的 第 一 部 分 看 到 。 如 果 给 定 的 表达 式 为 

， BUILD_BUG_ON 宏 就 会 抛 出 一 个 编译 时 错误 。 在 检查 后 的 下 一 步 ， 我 们 可 以 看 到 对 
early_ioremap_setup 子 数 的 调用 ， 这 个 函数 定义 在 mm/early ioremap.c 文件 中 。 这 个 函数 

代表 了 对 ioremap 的 大 体 初始 化 。 early_ioremap_setup 函数 用 初期 固定 映射 的 地 址 填充 了 
slot virt 数组 。 所 有 初期 定 映 射 地 址 在 内 存 中 都 在 __end_of_permanent_fixed_addresses 

后 面 ， 它 们 从 FIX_BITMAP_BEGIN 开始 ， 到 FIX_BITMAP_END 结束 。 实 际 上 初期 ioremap 会 


使 用 512 个 临时 引导 时 映射 : 


jus aH 


#define NR_FIX_BTMAPS 64 
#define FIX_BTMAPS_SLOTS 8 
#define TOTAL_FIX_BTMAPS (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS) 


early_ioremap_setup 如 下 : 


void _ init early_ioremap_setup(void) 


{ 
dime ay 
for (i = 0; i < FIX_BTMAPS_SLOTS; i++) 
if (WARN_ON(prev_map[i])) 
break; 
for (i = 0; i < FIX_BTMAPS_SLOTS; i++) 
slot_virt[i] = __fix_to_virt(FIX_BTMAP_BEGIN - NR_FIX_BTMAPS*i); 
} 


slot_virt 和 其 他 数组 定义 在 同一 个 源 文件 中 : 


static void _ iomem *prev_map[FIX_BTMAPS_SLOTS] __initdata; 
static unsigned long prev_size[FIX_BTMAPS_SLOTS] __initdata; 
static unsigned long slot_virt[FIX_BTMAPS_SLOTS] __initdata; 


slot_virt 包含 了 定 映射 区 域 的 虚拟 地 址 ” prev_map 数组 包含 了 初期 ioremap 区 域 的 地 
址 。 注 意 我 在 上 文中 提 到 的 : 实际 上 初期 ioremap 会 使 用 512 个 临时 引导 时 映射 ， 同 时 你 可 以 看 到 
所 有 的 数组 都 使 用 _initdata 定义 ， 这 意味 着 这 些 内 存 都 会 在 内 核 初始 化 结束 后 释放 掉 。 
在 early_ioremap_setup 结束 后 ， 我 们 获得 了 页 中 部 目录 ， 以 early_ioremap_pmd 函数 开始 
的 早期 ioremap ， early_ioremap_pmd 函数 只 能 获得 内 存 全 局 目录 以 及 为 给 定 地 址 计算 页 中 
部 目录 : 


static inline pmd_t * _ init early_ioremap_pmd(unsigned long addr) 


{ 
pgd_t *base = __va(read_cr3()); 
pgd_t *pgd = &base[pgd_index(addr)]; 
pud_t *pud = pud_offset(pgd, addr); 
pmd_t *pmd = pmd_offset(pud, addr); 
return pmd; 

} 


之 后 我 们 用 0 填充 bm_pte (早期 ioremap 页 表 入 口 )， 然 后 调用 pmd_populate_kernel $ 
数 : 


pmd = early_ioremap_pmd(fix_to_virt(FIX_BTMAP_BEGIN) ); 
memset(bm_pte, 0, sizeof(bm_pte)); 
pmd_populate_kernel(&init_mm, pmd, bm_pte); 


pmd_populate_kernel 函数 有 三 个 参数 : 


e init mm - init 进程 的 内 存 描述 符 (你 可 以 在 前 文中 看 到 ); 
e pmd - ioremap 定 映 射 开 始 处 的 页 中 部 目录 ; 
© bm pte -初期 ioremap 页 表 入 口 数组 定义 为 : 


static pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] _ page aligned_bss; 


pmd_popularte_kernel 函数 定义 在 arch/x86/include/asm/pgalloc.h 中 。 它 会 用 给 定 的 页 表 入 
口 ( bm_pte ) 生 成 给 定 页 中 部 目录 ( pmd ): 


static inline void pmd_populate_kernel(struct mm_struct *mm, 
pmd_t *pmd, pte_t *pte) 


paravirt_alloc_pte(mm, __pa(pte) >> PAGE_SHIFT); 
set_pmd(pmd, __pmd(__pa(pte) | _PAGE_TABLE)); 


set_pmd 声明 如 下 : 


#define set_pmd(pmdp, pmd) native_set_pmd(pmdp, pmd) 


native_set_pmd 声明 如 下 : 


static inline void native_set_pmd(pmd_t *pmdp, pmd_t pmd) 
{ 

“pmdp = pmd; 
} 


到 这 里 初期 ioremap 就 可 以 使 用 了 。 在 early_ioremap_init 函数 中 有 许多 检查 ， 但 是 都 不 
重要 ， 总 之 ioremap 的 初始 化 结束 了 。 


初期 输入 输出 重 映射 的 使 用 


初期 ioremap 初始 化 完成 后 ， 我 们 就 能 使 用 它 了 。 它 提供 了 两 个 函数 : 


e early ioremap 
e early iounmap 


用 于 从 10 物理 地 址 映射 /解除 映射 到 虚拟 地 址 。 这 俩 函数 都 依赖 于 coNFIG mmu 编译 配置 选 
项 。 内 存 管 理 单元 是 内 存 管理 的 一 种 特殊 块 。 这 种 块 的 主要 用 途 是 将 物理 地 址 转换 为 虚拟 地 
址 。 技 术 上 看 内 存 管理 单元 可 以 从 cr3 控制 寄存 器 中 获取 高 等 级 页 表 地 址 ( pgd )。 如 果 
CONFIG_MMU 选项 被 设 为 n ， early_ioremap 就 会 直接 返回 物理 地 址 ， 而 early_iounmap 就 
会 什么 都 不 做 。 另 一 方面 ， 如 果 设 为 y ， early_ioremap 就 会 调用 _early_ioremap ， 它 有 
三 个 参数 : 


e phys_addr -要 映射 到 虚拟 地 址 上 的 VO 内 存 区 域 的 基 物 理 地 址 ; 
e size -I/O 内 存 区 域 的 尺寸 ; 
e prot -页 表 入 口 位 。 


在 _early ioremap 中 我 们 首先 遍历 了 所 有 初期 ioremap 固定 映射 楼 并 检查 prev map 数组 
中 第 一 个 空闲 元 素 ， 然 后 将 这 个 值 存在 了 slot 变量 中 ， 另 外 设置 了 尺寸 : 


slot = -1; 
for (i = 0; i < FIX_BTMAPS_SLOTS; i++) { 
if (!prev_map[i]) { 
slot = i; 
break; 


prev_size[slot] = size; 
last_addr = phys_addr + size - 1; 


在 下 一 步 中 我 们 会 看 到 以 下 代码 : 


offset = phys_addr & ~PAGE_MASK; 
phys_addr &= PAGE_MASK; 
size = PAGE_ALIGN(last_addr + 1) - phys_addr; 


在 这 里 我 们 使 用 了 pace mask 用 于 清空 除 前 12 位 之 外 的 整个 phys_addr ° PAGE_MASK 宏 定 
义 如 下 : 


#define PAGE_MASK (~(PAGE_SIZE-1)) 


我 们 知道 页 的 尺寸 是 4096 个 字 节 或 用 二 进 制 表示 为 1000000000000 。 PAGE_SIZE - 1 就 会 
是 111111111111 ， 但 是 使 用 ~ 运算 后 我 们 就 会 得 到 go600666066@6 ， 然 后 使 用 
~PAGE_MASK 又 会 返回 111111111111 。 在 第 二 行 我 们 做 了 同样 的 事情 但 是 只 是 清空 了 前 12 
个 位 ， 然 后 在 第 三 行 获取 了 这 个 区 域 的 页 对 齐 尺 寸 。 我 们 获得 了 对 齐 区 域 ， 接 下 来 就 需要 获 
取 新 的 ioremap 区 域 所 占用 的 页 的 数量 然后 计算 固定 映射 下 标 : 


nrpages = size >> PAGE_SHIFT; 
idx = FIX_BTMAP_BEGIN - NR_FIX_BTMAPS*slot; 


现在 我 们 用 给 定 的 物理 地 址 填充 了 国定 映射 区 域 。 循 环 中 的 每 一 次 迭代 ， 我 们 都 调用 一 次 
arch/x86/mm/ioremap.c 中 的 __early_set_fixmap 有 函数 ， 为 给 定 的 物理 地 址 加 上 页 的 大 小 
4096 ， 然 后 更 新 下 标 和 页 的 数量 : 


while (nrpages > 0) { 
__early_set_fixmap(idx, phys_addr, prot); 
phys_addr += PAGE_SIZE; 
--idx; 
--nrpages; 


_ early_set_fixmap 有 函数 为 给 定 的 物理 地 址 获取 了 页 表 入 口 (保存 在 bm_pte 中 ， 见 上 文 ) : 


pte = early_ioremap_pte(addr); 


在 early_ioremap_pte 的 下 一 步 中 我 们 用 pgprot_val 宏 检 查 了 给 定 的 页 标志 ， 依 赖 这 个 标 


志 选 择 调用 set_pte 还 是 pte_clear 


if (pgprot_val(flags)) 
set_pte(pte, pfn_pte(phys >> PAGE_SHIFT, flags)); 
else 
pte_clear(&init_mm, addr, pte); 


As you can see above, we passed FIxMAP_PAGE_I0 as flags to the __early_ioremap . 
FIXMPA_PAGE_IO expands to the: 就 像 你 看 到 的 ， 我 们 将 FIxMAP_PAGE_I0 作为 标志 传 入 了 
_early_ioremap ° FIXMPA_PAGE_I0 从 以 下 





(__PAGE_KERNEL_EXEC | _PAGE_NX) 


标志 拓展 而 来 ， 所 以 我 们 调用 set_pte 来 设置 页 表 入 口 ， 就 像 set_pmd 一 样 ， 只 不 过 用 于 
PTE ( 见 上 文 )。 我 们 在 循环 中 设 定 了 所 有 pte ， 我 们 可 以 看 到 _ flush_tlb_one 的 函数 调 
用 : 


__flush_tlb_one(addr); 


这 个 函数 定义 在 arch/x86/include/asm/tlbflush.h 中 ， 并 通过 判断 cpu_has_invlpg 的 值 来 决定 
调用 __ flush_tlb_single 还 是 _ flush_tlb 


static inline void __flush_tlb_one(unsigned long addr) 


{ 
if (cpu_has_invlpg) 
__flush_tlb_single(addr); 
else 
__flush_tlb(); 
} 


_ flush_tlb_one SAR TLB 中 的 给 定 地 址 失效 。 就 像 你 看 到 的 我 们 更 新 了 页 结构 ， 但 是 
TLE 还 没有 改变 ， 这 就 是 我 们 需要 手动 做 这 件 事 情 的 原因 。 有 两 种 方法 做 这 件 事 。 第 一 种 是 
更 新 cr3 寄存 器 ， _flush tlh 函数 就 是 这 么 做 的 : 


native_write_cr3(native_read_cr3()); 


第 二 种 方法 是 使 用 inip 命令 来 使 TLB 入 口 失效 。 让 我 们 看 看 _flush_tlb_one 的 实 
现 。 就 像 我 们 所 看 到 的 ， 它 首先 检查 了 cpu_has_invlpg ， 定 义 如 下 : 


#if defined(CONFIG_X86_INVLPG) || defined(CONFIG_X86_64) 


# define cpu_has_invlpg 1 

#else 

# define cpu_has_invlpg (boot_cpu_data.x86 > 3) 
#endif 


如 果 CPU 支持 invlpg 指令 ， 我 们 就 调用 __flush_tlb_single 宏 ， 它 拓 展 自 


native_flush_tlb_single 





static inline void native_flush_tlb_single(unsigned long addr) 


{ 





asm volatile("invlpg (%0)" ::"r" (addr) : "memory"); 


__flush_tlb 的 调用 知识 更 新 了 cr3 寄存 Bo 在 这 步 结 束 之 后 __early_set_fixmap 函数 就 

执行 完了 ， 我 们 又 可 以 回 到 _early ioremap 的 实现 了 。 因 为 我 们 为 给 定 的 地 址 设 定 了 国定 
映射 区 域 ， 我 们 需要 将 VO 重 映射 的 区 域 的 基 庶 拟 地 址 用 slot 下 标 保 存在 prev_map 数组 
中 。 


prev_map[slot] = (void __iomem *)(offset + slot_virt[slot]); 


然后 返回 它 。 


第 二 个 函数 是 early_iounmap ， 它 会 解除 对 一 个 |/O 内 存 区 域 的 映射 。 这 个 函数 有 两 个 参 
数 : 基地 址 和 W/O 区 域 的 大 小 ， 这 看 起 来 与 early ioremap 很 像 。 它 同样 遍历 了 固定 映射 模 
并 寻找 给 定 地 址 的 樟 。 这 样 它 就 获得 了 这 个 固定 映射 楼 的 下 标 ， 然 后 通过 判断 
after_paging_init 的 值 决定 是 调用 __late_clear_fixmap 还 是 _early_set fixmap ° 当 这 
个 值 是 0 时 会 调用 ”early set fixmap 。 最 终 它 会 将 |/O 内 存 区 域 设 为 NULL 


prev_map[slot] = NULL; 
这 就 是 关于 fixmap 和 ioremap 的 全 部 内 容 。 当然 这 部 分 不 可 能 包含 所 有 ioremap 的 特 


性 ， 仅 仅 是 讲解 了 初期 ioremap ， 常规 的 ioremap 没有 讲 。 这 主要 是 因为 在 讲解 它 之 前 需要 
了 解 更 多 内 容 才 行 。 


就 是 这 样 ! 


By) CW ay aae Ioremap 


讲解 内 核 内 存 管理 的 第 一 部 分 到 此 结束 ， 如 果 你 有 任何 的 问题 或 者 建议 ， 你 可 以 直接 发 消息 
给 我 twitter， 也 可 以 给 我 发 邮件 或 是 直接 创建 一 个 issue。 


英文 不 是 我 的 母语 。 如 果 你 发 现 我 的 英文 描述 有 任何 问题 ， 请 提交 一 个 PR 到 linux-insides. 
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相关 连接 : 


e apic 

èe vsyscall 

e Intel Trusted Execution Technology 
e Xen 

e Real Time Clock 

e e820 

e Memory management unit 

e TLB 

e Paging 
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Linux 内 核 内 存 管理 第 三 节 


内 核 中 kmemcheck 介绍 


Linux 内 存 管 理 章 节 描 述 了 Linux 内 核 中 内 存 管 理 ; 本 小 节 是 第 三 部 分 。 在 本 章 第 二 节 中 我 们 
遇 到 了 两 个 与 内 存 管 理 相 关 的 概念 : 


@ 固定 映射 地 址 | 
@ 输入 输出 重 映射 . 


国定 映射 地 址 代表 虚拟 内 存 中 的 一 类 特殊 区 域 ， 这 类 地 址 的 物理 映射 地 址 是 在 编译 期 间 计 算 
出 来 的 。 输 入 输出 重 映射 表示 把 输入 /输出 相关 的 内 存 映射 到 虚拟 内 存 。 


例如 ， 查 看 /proc/iomem 命令 : 


$ sudo cat /proc/iomem 


00000000-00000fF fF : reserved 
00001000-0009d7fFF : System RAM 
0009d800-0009fF FFF : reserved 
000a0000-000bfFFF : PCI Bus 0000:00 
000c0000-000cffFFF : Video ROM 
000d0000-000d3ffF : PCI Bus 0000:00 
000d4000-000d7ffF : PCI Bus 0000:00 
000d8000-000dbfff : PCI Bus 0000:00 
000dc000-000dffff : PCI Bus 0000:00 
000e0000-000fffff : reserved 


iomem 命令 的 输出 显示 了 系统 中 每 个 物理 设备 所 映射 的 内 存 区 域 。 第 一 列 为 物理 设备 分 配 的 
内 存 区 域 ， 第 二 列 为 对 应 的 各 种 不 同类 型 的 物理 设备 。 再 例如 : 


$ sudo cat /proc/ioports 


Q000-Ocf7 : PCI Bus 0000:00 
0000-001f : dmal 
0020-0021 : pict 
0040-0043 : timer0 
0050-0053 : timer1 
0060-0060 : keyboard 
0064-0064 : keyboard 
0070-0077 : rtcO 
0080-008f : dma page reg 
Q0a0-00a1 : pic2 
00c0-00df : dma2 
oofo-ooff : fpu 

00f0-00f0 : PNPOCO4:00 

03c0-03df : vgat 
03f8-03ff : serial 
04d0-04d1 : pnp 00:06 
0800-087f : pnp 00:01 
Qa00-OaOf : pnp 00:04 
0a20-0a2f : pnp 00:04 
0a30-0a3f : pnp 00:04 


ioports 的 输出 列 出 了 系统 中 物理 设备 所 注册 的 各 种 类 型 的 |/O 端 口 。 内 核 不 能 直接 访问 设备 

的 输入 /输出 地 址 。 在 内 核能 够 使 用 这 些 内 存 之 前 ， 必 须 将 这 些 地 址 映射 到 虚拟 地 址 空间 ， 这 

就 是 io remap 机 制 的 主要 目的 。 在 前 面 第 二 节 中 只 介绍 了 早期 的 io remap ° 很 快 我 们 就 要 

a 看 常规 的 io remap 实现 机 制 。 但 在 此 之 前 ， 我 们 需要 学 习 一 些 其 他 的 知识 ， 例 如 不 
类 型 的 内 存 分 配器 等 ， 不 然 的 话 我 们 很 难 理解 该 机 制 。 


在 进入 Linux 内 核 常 规 期 的 内 存 管理 之 前 ， 我 们 要 看 一 些 特 殊 的 内 存 机 制 ， 例 如 调试 ， 检 查 内 
存 泄 漏 ， 内 存 控制 等 等 。 学 习 这 些 内容 有 助 于 我 们 理解 Linux 内 核 的 内 存 管理 。 


从 本 节 的 标题 中 ， 你 可 能 已 经 看 出 来 ， 我 们 会 从 kmemcheck 开 始 了 解 内 存 机 制 。 和 前 面 的 章 
节 一 样 ， 我 们 首先 从 理论 上 学 习 什 么 是 kmemcheck ， 然 后 再 来 看 Linux 内 核 中 是 怎么 实现 这 一 
机 制 的 。 


让 我 们 开始 吧 。Linux 内 核 中 的 kmemcheck 到 底 是 什么 呢 ? 从 该 机 制 的 名 称 上 你 可 能 已 经 猜 
到 ， kmemcheck 是 检查 内 存 的 。 你 猜 的 很 对 。 kmemcheck 的 主要 目的 就 是 用 来 检查 是 否 有 内 
核 代码 访问 未 初始 化 的 内 存 。 让 我 们 看 一 个 简单 的 C 程序 : 


#include <stdlib.h> 
#include <stdio.h> 


SENCA 
int a; 


}; 


int main(int argc, char **argv) { 
struct A *a = malloc(sizeof(struct A)); 
printf("a->a = %d\n", a->a); 
return 0; 


在 上 面 的 程序 中 我 们 给 结构 体 A 分 配 了 内 存 ， 然 后 我 们 尝试 打印 它 的 成 员 a 。 如 果 我 们 不 使 
用 其 他 选项 来 编译 该 程序 : 


gcc test.c -o test 


编译 器 不 会 显示 成 员 a 未 初始 化 的 提示 信息 。 但 是 如 果 使 用 工具 valgrind 来 运行 该 程序 ， 我 
们 会 看 到 如 下 输出 : 


~$  valgrind --leak-check=yes ./test 

==28469== Memcheck, a memory error detector 

==28469== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. 
==28469== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info 
==28469== Command: ./test 


==28469== 

==28469== Conditional jump or move depends on uninitialised value(s) 
==28469== at Ox4E820EA: vfprintf (in /usr/1ib64/libc-2.22.so0) 
==28469== by Ox4E88D48: printf (in /usr/lib64/libc-2.22.so0) 
==28469== by ©x4005B9: main (in /home/alex/test) 

==28469== 

==28469== Use of uninitialised value of size 8 

==28469== at Ox4E7EOQBB: _itoa_word (in /usr/1ib64/libc-2.22.s0) 
==28469== by Ox4E8262F: vfprintf (in /usr/1ib64/libc-2.22.s0) 
==28469== by Ox4E88D48: printf (in /usr/lib64/libc-2.22.so0) 
==28469== by ©x4005B9: main (in /home/alex/test) 


实际 上 kmemcheck 在 内 核 空间 做 的 事情 ， 和 valgrind 在 用 户 空间 做 的 事情 是 一 样 的 ， 都 是 
用 来 检测 未 初始 化 的 内 存 。 


要 想 在 内 核 中 启用 该 机 制 ， 需 要 在 配置 内 核 时 开启 CONFIG KMEMCHECK 选项 : 


Kernel hacking 
-> Memory Debugging 


Memory Debugging 
Arrow keys navigate the menu. <Enter> selects submenus ---> (or empty submenus ----). Highlighted letters are hotkeys. Pressing <Y> includes, <N> excludes, <M> modularizes 
features. Press <Esc><Esc> to exit, <?> for Help, </> for Search. Legend: [*] built-in [ ] excluded <M> module < > module capable 


] Extend memmap on extra space for more information on page 
] Poison pages after freeing 

] Debug object operations 

] Enable SLUB performance statistics 
] Kernel memory leak detector 

] Stack utilization instrumentation 
] Debug VM 

] Debug VM translations 

] Debug memory initialisation 

] Debug access to per_cpu maps 

] Check for stack overflows 


] kmemcheck: trap use of uninitialized memory --->| 


[ 
[ 
[ 
[ 
[ 
[ 
[ 
[ 
fy 
【 
[* 
tr 





<Exit> <Help> <Save> <Load> 





kmemcheck 机 制 还 提供 了 一 些 内 核 配 置 参 数 ， 我 们 可 以 在 下 一 个 段落 中 看 到 所 有 的 可 选 参 
数 。 最 后 一 个 需要 注意 的 是 ， kmemcheck 仅 在 x86 64 体系 中 实现 了 。 为 了 确信 这 一 点 ， 我 
们 可 以 查看 x86 的 内 核 配置 文件 arch/x86/Kconfig : 


config X86 


select HAVE_ARCH_KMEMCHECK 


因此 ， 对 于 其 他 的 体系 结构 来 说 是 没有 kmemcheck 功能 的 。 


现在 我 们 知道 了 kmemcheck 可 以 检测 内 核 中 未 初始 化 内 存 的 使 用 情况 ， 也 知道 了 如 何 开 启 这 个 
HAE o ARZ kmemcheck 是 怎么 做 检测 的 呢 ? 当 内 核 尝试 分 配 内 存 时 ， 例 如 如 下 一 段 代码 : 


struct my_struct *my_struct = kmalloc(sizeof(struct my_struct), GFP_KERNEL); 


KA BYTE > TEA KAIF FI page 时 会 发 生 缺 页 中 断 。 这 是 由 于 kmemcheck 将 内 存 页 标记 
为 不 存在 〈 关 于 Linux 内 存 分 页 的 相关 信息 ， 你 可 以 参考 分 页 ) 。 如 果 一 个 缺 页 中 断 异常 发 生 
了 ， 异 常 处 理 程序 会 来 处 理 这 个 异常 ， 如 果 异 常 处 理 程序 检测 到 内 核 使 能 了 kmemcheck ， 那 
么 就 会 将 控制 权 提 交 给 kmemcheck 来 处 理 ; kmemcheck 检查 完 之 后 ， 该 内 存 页 会 被 标记 为 


present ， 然 后 被 中 断 的 程序 得 以 继续 执行 下 去 。 这 里 的 处 理 方式 比较 巧妙 ， 被 中 断 程序 的 
第 一 条 指令 执行 时 ， kmemcheck 又 会 标记 内 存 页 为 not present ， 按 照 这 种 方式 ， 下 一 个 对 
内 存 页 的 访问 也 会 被 捕获 。 


目前 我 们 只 是 从 理论 层面 考察 了 kmemcheck ， 接 下 来 我 们 看 一 下 Linux 内 核 是 怎么 来 实现 该 机 
制 的 。 


kmemcheck 机 制 在 Linux 内 核 中 的 实现 


我 们 应 该 已 经 了 解 kmemcheck 是 做 什么 的 以 及 它 在 Linux 内 核 中 的 功能 ， 现 在 是 时 候 看 一 下 它 
在 Linux 内 核 中 的 实现 。 kmemcheck 在 内 核 的 实现 分 为 两 部 分 。 第 一 部 分 是 架构 无 关 的 部 分 ， 
位 于 源码 mm/kmemcheck.c ; 第 二 部 分 x86 64 架构 相关 的 部 分 位 于 目 

录 arch/x86/mm/kmemcheck 中 。 


我 们 先 分 析 该 机 制 的 初始 化 过 程 。 我 们 已 经 知道 要 在 内 核 中 使 能 kmemcheck 机 制 ， 需 要 开局 
内 核 的 CONFIG_KMEMCHECK 配置 项 。 除 了 这 个 选项 ， 我 们 还 需要 给 内 核 command line 传 递 一 个 


kmemcheck 参数 : 


e kmemcheck=0 (disabled) 
e kmemcheck=1 (enabled) 
e kmemcheck=2 (one-shot mode) 


前 面 两 个 值得 含义 很 明确 ， 但 是 最 后 一 个 需要 解释 。 这 个 选项 会 使 kmemcheck 进入 一 种 特殊 
的 模式 : 在 第 一 次 检测 到 未 初始 化 内 存 的 使 用 之 后 ， 就 会 关闭 kmemcheck 。 实 际 上 该 模式 是 
内 核 的 默认 选项 : 


kmencheck: trap use of uninitialized memory 
Arrow keys navigate the menu. <Enter> selects submenus ---> (or empty submenus ----). Highlighted letters are hotkeys. Pressing <Y> includes, <N> excludes, <M> modularizes 
it, <?> for Help, </> for Search. Legend: [*] built-in [ ] excluded <M> module < > module capable 


features. Press <Esc><Esc> to ex 


= kmemcheck: trap use of uninitialized memor 
heck: default mode at boot (one-shot) --->| 
: error queue size 
eck: shadow copy size (5 => 32 bytes, 6 => 64 bytes) 
: allow partially uninitialized memory 
kmemcheck: allow bit-field manipulation 





< Exit > < Help > <Save> < Load > 








从 Linux 初 始 化 过 程 章节 的 第 七 节 part 中 ， 我 们 知道 在 内 核 初 始 化 过 程 中 ， 会 在 
do_initcall_level , do_early_param 等 函数 中 解析 内 核 Command line。 前 面 也 提 到 过 
kmemcheck 子 系 统 由 两 部 分 组 成 ， 第 一 部 分 启动 比较 早 。 在 源码 mm/kmemcheck.c 中 有 一 个 
函数 param kmemcheck ， 该 函数 在 command line 解 析 时 就 会 用 到 : 


static int __init param_kmemcheck(char *str) 


{ 
int val; 
int ret; 


if (!str) 
return -EINVAL 


ret = kstrtoint(str, 0, &val); 
if (ret) 

return ret; 
kmemcheck_enabled = val; 
return 0; 


early_param("kmemcheck", param_kmemcheck) ; 


从 前 面 的 介绍 我 们 知道 param_kmemcheck 可 能 存在 三 种 情况 : o (4848), 1 (禁止 )or 2 (一 
oe 。 param_kmemcheck 的 实现 很 简单 : 将 command line 传 递 的 kmemcheck 参数 的 值 由 字 
符 串 转换 为 整数 ， 然 后 赋值 给 变量 kmemcheck_enabled ° 


第 二 阶段 在 内 核 初始 化 阶段 执行 ， 而 不 是 在 早期 初始 化 过 程 initcalls 。 第 二 阶 断 的 过 程 体现 在 


kmemcheck_init 


int __init kmemcheck_init(void) 


{ 


early_initcall(kmemcheck_init); 


kmemcheck_init 的 主要 目 的 就 是 调用 kmemcheck_selftest LE E 并 检查 它 的 返回 值 : 


if (!kmemcheck_selftest()) { 
printk(KERN_INFO "kmemcheck: self-tests failed; disabling\n"); 
kmemcheck_enabled = 0; 
return -EINVAL; 


printk(KERN_INFO "kmemcheck: Initialized\n"); 


如 果 kmemcheck_init 检测 失败 > 就 返回 EINVAL ° kmemcheck_selftest 函数 会 检测 内 存 访 
问 相 关 的 操作 码 (例如 rep movsb ，movzwq ) 的 大 小 。 如 果 检 测 到 的 大 小 的 实际 大 小 是 一 臻 
ÁJ > kmemcheck_selftest 返回 true °? GAW false ° 


如 果 如 下 代码 被 调用 : 


struct my_struct *my_struct = kmalloc(sizeof(struct my_struct), GFP_KERNEL); 


经 过 一 系列 的 函数 调用 ， kmem_getpages 部 数 会 被 调用 到 ， 该 函数 的 定义 在 源码 mm/slab.c 
中 ， 该 函数 的 主要 功能 就 是 尝试 按照 指定 的 参数 需求 分 配 内 存 页 。 在 该 函数 的 结尾 处 有 如 下 
代码 : 


if (kmemcheck_enabled && !(cachep->flags & SLAB_NOTRACK)) { 
kmemcheck_alloc_shadow(page, cachep->gfporder, flags, nodeid); 


if (cachep->ctor) 
kmemcheck_mark_uninitialized_pages(page, nr_pages); 
else 


kmemcheck_mark_unallocated_pages(page, nr_pages); 


这 段 代 码 判断 如 果 kmemcheck 使 能 ， 并 且 参 数 中 未 设置 SLAB_NOTRACK ， 那 么 就 给 分 配 的 内 
存 页 设置 non-present 标记 。 SLAB_NOTRACK 标记 的 含义 是 不 跟踪 未 初始 化 的 内 存 。 另 外 ， 
WRG MRA HE BR (细节 在 下 面 描述 ) ， 所 分 配 的 内 存 页 标记 为 未 初始 化 ， 否 则 标记 
为 未 分 配 。 kmemcheck_alloc_shadow 函数 在 源码 mm/kmemcheck.c 中 ， 其 基本 内 容 如 下 : 


void kmemcheck_alloc_shadow(struct page *page, int order, gfp_t flags, int node) 


{ 


struct page *shadow; 
shadow = alloc_pages_node(node, flags | __GFP_NOTRACK, order); 


for(i = 0; i < pages; ++i) 
page[i].shadow = page_address(&shadow[i]); 


kmemcheck_hide_pages(page, pages); 


HAA shadow bits 分 配 内 存 ， 并 为 内 存 页 设置 shadow 位 。 如 果 内 存 页 设置 了 该 标记 ， 就 意 
味 着 kmemcheck 会 跟踪 这 个 内 存 页 ° 最 后 调用 kmemcheck_hide_pages AX 

kmemcheck_hide_pages 是 体系 结构 相关 的 函数 ， 其 代码 在 
arch/x86/mm/kmemcheck/kmemcheck.c 源码 中 。 该 函数 的 功能 是 为 指定 的 内 存 页 设置 non- 
present 标记 。 该 函数 实现 如 下 : 


void kmemcheck_hide_pages(struct page *p, unsigned int n) 


{ 
unsigned int i; 
for (i = 0; i <n; ++i) { 
unsigned long address; 
pte_t “pte; 
unsigned int level; 
address = (unsigned long) page_address(&p[i]); 
pte = lookup_address(address, &level); 
BUG_ON(!pte); 
BUG_ON(level != PG_LEVEL_4K); 
set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_PRESENT) ); 
set_pte(pte, __pte(pte_val(*pte) | _PAGE_HIDDEN)); 
__flush_tlb_one(address); 
} 
} 


该 函数 遍历 参数 代表 的 所 有 内 存 页 ， 并 尝试 获取 每 个 内 存 页 的 TAR 。 如 果 获 取 成 功 ， 清 二 

页 表 项 的 present 标记 ， 设 置 页 表 项 的 hidden 标记 。 在 最 后 还 需要 刷新 TLB ,因为 有 一 些 内 

页 已 经 发 生 了 改变 。 从 这 个 地 方 开始 ， AER 就 进入 kmemcheck 的 跟踪 系统 。 由 于 内 存 页 的 
present 标记 被 清 了 除了， 一旦 kmalloc 返回 了 内 存 地 址 ， 并 且 有 代码 访问 这 个 地 址 ， 就 会 触 
发 缺 页 中 断 。 


在 Linux 内 核 初 始 化 的 第 二 节 介 绍 过 ， 缺 页 中 断 处 理 程序 是 arch/x86/mm/fault.c 的 
do_page_fault 函数 。 该 函数 开始 部 分 如 下 : 


static noinline void 
__do_page_fault(struct pt_regs *regs, unsigned long error_code, 
unsigned long address) 


if (kmemcheck_active(regs) ) 
kmemcheck_hide(regs); 


kmemcheck_active 函数 获取 kmemcheck_context per-cpu 结构 体 ， 并 返回 该 结构 体 成 员 
balance 和 0 的 比较 结果 : 


bool kmemcheck_active(struct pt_regs *regs) 


{ 


struct kmemcheck_context *data = this_cpu_ptr(&kmemcheck_context); 


return data->balance > 0; 


kmemcheck_context 结构 体 代 表 kmemcheck 机 制 的 当前 状态 。 其 内 部 保存 了 未 初始 化 的 地 
址 ， 地 址 的 数量 等 信息 。 其 成 员 balance 代表 了 kmemcheck 的 当前 状态 ， 换 句 话 

说 ， balance 表示 kmemcheck 是 否 已 经 隐藏 了 内 存 页 。 如 果 data->balance KTO? 
kmemcheck_hide 函数 会 被 调用 。 这 总 意味 着 kmemecheck 已 经 设置 了 内 存 页 页 的 present 标 

记 ， 但 是 我 们 需要 再 次 隐藏 内 存 页 以 便 触 发 下 一 次 的 缺 页 中 断 。 kmemcheck_hide 函数 会 清理 
内 存 页 的 present 标记 ， 这 表示 一 次 kmemcheck 会 话 已 经 完成 ， igi 页 中 断 会 再 次 被 触 
发 。 在 第 一 步 ， 由 于 data->balance 值 为 0， 所 以 kmemcheck_active 会 返回 false， 所 以 
kmemcheck_hide 也 不 会 被 调用 。 接 下 来 ， 我 们 看 do_page_fault 的 下 一 行 代码 : 


if (kmemcheck_fault(regs, address, error_code) ) 
return; 


首先 kmemcheck_fault 函数 检查 引起 错误 的 真实 原因 2 第 一 步 先 检 查 标 记 寄 存 器 以 确认 进程 
是 否 处 于 正常 的 内 核 态 : 


if (regs->flags & X86_VM_MASK) 
return false; 

if (regs->cs != __KERNEL_CS) 
return false; 


如 果 检 测 失 败 , 表明 这 不 是 kmemcheck 相关 的 缺 页 中 断 ” kmemcheck_fault 会 返回 false。 如 
果 检 测 成 功 ， 接 下 来 查找 发 生 异 常 的 地 址 的 RAR ， 如 果 找 不 到 页 表 项 ， 函 数 返 回 false: 


pte = kmemcheck_pte_lookup(address) ; 
if (!pte) 
return false; 


kmemcheck_fault 最 后 一 步 是 调用 kmemcheck_access Be > HE hy BK Ho HM 48 定 内 存 页 的 访 
问 ， 并 设置 该 内 存 页 的 present 标 记 。 kmemcheck_access 哆 数 做 了 大 部 分 工作 ， 它 检查 引起 
缺 页 异常 的 当前 指令 ， 如 果 检 查 到 了 错误 ， 那 么 会 把 该 错误 的 上 下 文保 存 到 环形 队列 中 : 


static struct kmemcheck_error error_fifo[CONFIG_KMEMCHECK_QUEUE_SIZE]; 


kmemcheck 声明 了 一 个 特殊 的 tasklet : 


static DECLARE_TASKLET(kmemcheck_tasklet, &do_wakeup, 0); 


该 tasklet 被 调度 执行 时 ， 会 调用 do wakeup 函数 ， 该 函数 位 于 
arch/x86/mm/kmemcheck/error.c 文件 中 。 


do_wakeup 函数 调用 kmemcheck_error_recall 函数 以 便 将 kmemcheck 检测 到 的 错误 信息 输 


出 o 


kmemcheck_show(regs); 


kmemcheck_fault PEES RAY 会 调用 kmemcheck_show ho KR 函数 会 再 次 设置 内 存 页 的 


present 标 记 。 


if (unlikely(data->balance != 0)) { 
kmemcheck_show_all(); 
kmemcheck_error_save_bug(regs) ; 
data->balance = 0; 
return; 


kmemcheck_show_all 函数 会 针对 每 个 地 址 调用 kmemcheck_show_addr 


static unsigned int kmemcheck_show_all(void) 

{ 
struct kmemcheck_context *data = this_cpu_ptr(&kmemcheck_context); 
unsigned int i; 
unsigned int n; 


n= 0; 
for (i = 0; 1 < data->n_addrs; ++i) 


n += kmemcheck_show_addr(data->addr[i]); 


return n; 


kmemcheck_show_addr Be Be A 容 如 F: 


int kmemcheck_show_addr(unsigned long address) 


{ 
pte_t “pte; 


pte = kmemcheck_pte_lookup(address) ; 
if (!pte) 
return 0; 


set_pte(pte, _ pte(pte_val(*pte) | _PAGE_PRESENT)); 
__flush_tlb_one(address); 
return 1; 


在 函数 kmemcheck_show 的 结尾 处 会 设置 TF 标记 : 


if (!(regs->flags & X86_EFLAGS_TF)) 
data->flags = regs->flags; 


我 们 之 所 以 这 么 处 理 ， 是 因为 我 们 在 内 存 页 的 缺 页 中 断 处理 完 后 需要 再 次 隐藏 内 存 页 。 当 
TF 标记 被 设置 后 ， 处 理 器 在 执行 被 中 断 程序 的 第 一 条 指令 时 会 进入 单 步 模式 ， 这 会 触发 
debug 异常 。 从 这 个 地 方 开始 ， 内 存 页 会 被 隐藏 起 来 ， 执 行 流程 继续 。 由 于 内 存 页 不 可 见 ， 
那么 访问 内 存 页 的 时 候 又 会 触发 缺 页 中 断 ， 然 后 kmemcheck 就 有 机 会 继续 检测 /收集 并 显示 内 
存 错误 信息 。 


到 这 里 kmemcheck 的 工作 机 制 就 介绍 完毕 了 。 


结束 语 


Linux 内 核 内 存 管 理 第 三 节 介 绍 到 此 为 止 。 如 果 你 有 任何 疑问 或 者 建议 ， 你 可 以 直接 给 我 DXAX 
发 消息 ， 发 邮件 ， 或 者 创建 一 个 issue 。 在 接 下 来 的 小 节 中 ， 我 们 来 看 一 下 另 一 个 内 存 调试 
工具 - kmemleak ° 


英文 不 是 我 的 母语 。 如 果 你 发 现 我 的 英文 描述 有 任何 问题 ， 请 提交 一 个 PR 到 linux-insides. 
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这 个 章节 描述 了 Linux 内 核 中 的 控制 组 机 制 。 


。 简介 


Control Groups 


Introduction 


This is the first part of the new chapter of the linux insides book and as you may guess by 
part's name - this part will cover contro! groups or cgroups mechanism in the Linux kernel. 


Cgroups are special mechanism provided by the Linux kernel which allows us to allocate 
kind of resources like processor time, number of processes per group, amount of memory 
per control group or combination of such resources for a process or set of processes. 

Cgroups are organized hierarchically and here this mechanism is similar to usual processes 
as they are hierarchical too and child cgroups inherit set of certain parameters from their 
parents. But actually they are not the same. The main differences between cgroups and 
normal processes that many different hierarchies of control groups may exist simultaneously 
in one time while normal process tree is always single. This was not a casual step because 
each control group hierarchy is attached to set of control group subsystems . 


One control group subsystem represents one kind of resources like a processor time or 
number of pids or in other words number of processes for a control group . Linux kernel 
provides support for following twelve control group subsystems : 


e cpuset -assigns individual processor(s) and memory nodes to task(s) in a group; 

e cpu - uses the scheduler to provide cgroup tasks access to the processor resources; 

e cpuacct - generates reports about processor usage by a group; 

e io -sets limit to read/write from/to block devices; 

e memory -sets limit on memory usage by a task(s) from a group; 

e devices -allows access to devices by a task(s) from a group; 

e freezer - allows to suspend/resume for a task(s) from a group; 

e net_cls -allows to mark network packets from task(s) from a group; 

e net_prio - provides a way to dynamically set the priority of network traffic per network 
interface for a group; 

e perf_event - provides access to perf events) to a group; 

e hugetlb -activates support for huge pages for a group; 


pid - sets limit to number of processes in a group. 


Each of these control group subsystems depends on related configuration option. For 
example the cpuset subsystem should be enabled via coNFIG_cPUSETS kernel configuration 
option, the io subsystem via coNFIG_BLK_cGROUP kernel configuration option and etc. All of 


控制 组 简介 


these kernel configuration options may be found in the General setup > Control Group 


support Menu: 





You may see enabled control groups on your computer via proc filesystem: 


$ cat /proc/cgroups 


#subsys_name hierarchy 


cpuset 8 1 1 
cpu 7 66 dl 
cpuacct 7 66 
blkio 11 66 
memory 9 94 
devices 6 66 
freezer 2 all 
net_cls 4 1 
perf_event 3 1 
net_prio 4 1 
hugetlb 10 1 
pids 5 69 1 


or via sysfs: 


num_cgroups enabled 


621 


$ Js - /sys/fs/cgroup/ 
total 0 


dr-xr-xr-x 5 root root © Dec 2 22:37 blkio 

lrwxrwxrwx 1 root root 11 Dec 2 22:37 cpu -> cpu,cpuacct 
lrwxrwxrwx 1 root root 11 Dec 2 22:37 cpuacct -> cpu, cpuacct 
dr-xr-xr-x 5 root root © Dec 2 22:37 cpu,cpuacct 

dr-xr-xr-x 2 root root © Dec 2 22:37 cpuset 

dr-xr-xr-x 5 root root © Dec 2 22:37 devices 

dr-xr-xr-x 2 root root © Dec 2 22:37 freezer 

dr-xr-xr-x 2 root root © Dec 2 22:37 hugetlb 

dr-xr-xr-x 5 root root © Dec 2 22:37 memory 

lrwxrwxrwx 1 root root 16 Dec 2 22:37 net_cls -> net_cls,net_prio 
dr-xr-xr-x 2 root root © Dec 2 22:37 net_cls,net_prio 

lrwxrwxrwx 1 root root 16 Dec 2 22:37 net_prio -> net_cls,net_prio 
dr-xr-xr-x 2 root root 0 Dec 2 22:37 perf_event 

dr-xr-xr-x 5 root root © Dec 2 22:37 pids 

dr-xr-xr-x 5 root root © Dec 2 22:37 systemd 


As you already may guess that control groups mechanism is not such mechanism which 
was invented only directly to the needs of the Linux kernel, but mostly for userspace needs. 
To use a control group , we should create it at first. We may create a cgroup via two ways. 


The first way is to create subdirectory in any subsystem from /sys/fs/cgroup and add a pid 
of atask toa tasks file which will be created automatically right after we will create the 
subdirectory. 


The second way is to create/destroy/manage cgroups with utils from libcgroup library 
( libcgroup-tools in Fedora). 


Let's consider simple example. Following bash script will print a line to /dev/tty device 
which represents control terminal for the current process: 


#!/bin/bash 


while : 

do 
echo "print line" > /dev/tty 
sleep 5 

done 


So, if we will run this script we will see following result: 


$ sudo chmod +x cgroup_test_script.sh 
~$ ./cgroup_test_script.sh 

print line 

print line 

print line 


Now let's go to the place where cgroupfs is mounted on our computer. As we just saw, this 
is /sys/fs/cgroup directory, but you may mount it everywhere you want. 


$ cd /sys/fs/cgroup 


And now let's go to the devices subdirectory which represents kind of resources that allows 
or denies access to devices by tasks ina cgroup : 


# cd devices 


and create cgroup_test_group directory there: 


# mkdir cgroup_test_group 


After creation of the cgroup_test_group directory, following files will be generated there: 


/sys/fs/cgroup/devices/cgroup_test_group$ ls -1 
total 0 


-rw-r--r-- 1 root root © Dec 3 22:55 cgroup.clone_children 
-rw-r--r-- 1 root root 0 Dec 3 22:55 cgroup.procs 
--W------- 1 root root 0 Dec 3 22:55 devices.allow 
--W------- 1 root root 0 Dec 3 22:55 devices.deny 
-r--r--r-- 1 root root 0 Dec 3 22:55 devices.list 
-rw-r--r-- 1 root root © Dec 3 22:55 notify_on_release 
-rw-r--r-- 1 root root © Dec 3 22:55 tasks 


For this moment we are interested in tasks and devices.deny files. The first tasks files 
should contain pid(s) of processes which will be attached to the cgroup_test_group . The 
second devices.deny file contain list of denied devices. By default a newly created group 
has no any limits for devices access. To forbid a device (in our case itis /dev/tty ) we 
should write to the devices.deny following line: 


# echo "c 5:0 w" > devices.deny 


Let's go step by step through this line. The first c letter represents type of a device. In our 
case the /dev/tty iS char device . We can verify this from output of 1s command: 


~$ ls -1 /dev/tty 
crw-rw-rw- 1 root tty 5, © Dec 3 22:48 /dev/tty 


see the first c letter in a permissions list. The second part is 5:0 is minor and major 
numbers of the device. You can see these numbers in the output of 1s too. And the last w 
letter forbids tasks to write to the specified device. So let's start the cgroup_test_script.sh 
script: 


~$ ./cgroup_test_script.sh 
print line 
print line 
print line 


and add pid of this process to the devices/tasks file of our group: 


# echo $(pidof -x cgroup_test_script.sh) > /sys/fs/cgroup/devices/cgroup_test_group/ta 
sks 


The result of this action will be as expected: 


~$ ./cgroup_test_script.sh 

print line 

print line 

print line 

print line 

print line 

print line 

./cgroup_test_script.sh: line 5: /dev/tty: Operation not permitted 


Similar situation will be when you will run you docker) containers for example: 


~$ docker ps 


CONTAINER ID IMAGE COMMAND CREATED S 
TATUS PORTS NAMES 

fa2d2085cd1c mariadb:10 "docker-entrypoint..." 12 days ago U 
p 4 minutes 0.0.0.0:3306->3306/tcp mysql-work 


~$ cat /sys/fs/cgroup/devices/docker/fa2d2085cd1c8d797002c77387d2061f56fefb470892F140d 
Odc511bd4d9bb61/tasks | head -3 

5501 

5584 

5585 


So, during startup of a docker container, docker will create a cgroup for processes in this 
container: 


$ docker exec -it mysql-work /bin/bash 


$ top 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
1 mysql 20 
© 963996 101268 15744 S 0.0 0.6 0:00.46 mysqld 
71 root 20 0 20248 3028 
2732 S 0.0 0.0 0:00.01 bash 
77 root 20 0 21948 2424 2056 R 0.0 0.0 


0:00.00 top 


And we may see this cgroup on host machine: 


$ systemd-cgls 


Control group /: 

-.Sslice 

上 docker 

| l-fa2d2085cd1c8d797002c77387d2061f56fefb470892f140d0dc511bd4d9bb61 
| [5501 mysqld 

| 6404 /bin/bash 


Now we know a little about control groups mechanism, how to use it manually and what's 
purpose of this mechanism. Time to look inside of the Linux kernel source code and start to 
dive into implementation of this mechanism. 


Early initialization of control groups 


Now after we just saw little theory about control groups Linux kernel mechanism, we may 

start to dive into the source code of Linux kernel to acquainted with this mechanism closer. 

As always we will start from the initialization of control groups . Initialization of cgroups 

divided into two parts in the Linux kernel: early and late. In this part we will consider only 
early partand late part will be considered in next parts. 


Early initialization of cgroups starts from the call of the: 


cgroup_init_early(); 


function in the init/main.c during early initialization of the Linux kernel. This function is 
defined in the kernel/cgroup.c source code file and starts from the definition of two following 
local variables: 


int _ init cgroup_init_early(void) 

{ 
static struct cgroup_sb_opts __initdata opts; 
struct cgroup_subsys *ss; 


The cgroup_sb_opts structure defined in the same source code file and looks: 


struct cgroup_sb_opts { 
u16 subsys_mask; 
unsigned int flags; 
char *release_agent; 
bool cpuset_clone_children; 
char *name; 
bool none; 


}; 


which represents mount options of cgroupfs . For example we may create named cgroup 
hierarchy (with name my_cgrp ) with the name= option and without any subsystems: 


$ mount -t cgroup -oname=my_cgrp,none /mnt/cgroups 


The second variable - ss has type - cgroup_subsys structure which is defined in the 
include/linux/cgroup-defs.h header file and as you may guess from the name of the type, it 
represents a cgroup subsystem. This structure contains various fields and callback 
functions like: 


struct cgroup_subsys { 
int (*css_online)(struct cgroup_subsys_state *css); 
void (*css_offline)(struct cgroup_subsys_state *css); 


bool early_init:1; 

int id; 

const char *name; 

struct cgroup_root *root; 


Where for example css_online and css_offline callbacks are called after a cgroup 
successfully will complete all allocations and a cgroup will be before releasing respectively. 
The early_init flags marks subsystems which may/should be initialized early. The id 
and name fields represents unique identifier in the array of registered subsystems for a 
cgroup and name of a subsystem respectively. The last- root fields represents pointer to 
the root of of a cgroup hierarchy. 


Of course the cgroup_subsys structure is bigger and has other fields, but it is enough for 
now. Now as we got to know important structures related to cgroups mechanism, let's 
return to the cgroup_init_early function. Main purpose of this function is to do early 
initialization of some subsystems. As you already may guess, these early subsystems 
should have cgroup_subsys->early_init = 1 . Let's look what subsystems may be initialized 
early. 


After the definition of the two local variables we may see following lines of code: 


init_cgroup_root(&cgrp_dfl_root, &opts); 
cgrp_dfl_root.cgrp.self.flags |= CSS_NO_REF; 


Here we may see Call of the init_cgroup_root function which will execute initialization of 
the default unified hierarchy and after this we set css_No_REF flag in state of this default 

cgroup to disable reference counting for this css. The cgrp_dfl_root is defined in the 
same source code file: 


struct cgroup_root cgrp_dfl_root; 


Its cgrp field represented by the cgroup structure which represents a cgroup as you 
already may guess and defined in the include/linux/cgroup-defs.h header file. We already 
know that a process which is represented by the task_struct in the Linux kernel. The 


task_struct does not contain direct link to a cgroup where this task is attached. But it may 
be reached via css set field of the task_struct . This css_set structure holds pointer to 
the array of subsystem states: 


struct css_set { 


struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT]; 


And via the cgroup_subsys_state , a process may geta cgroup that this process is attached 
to: 


struct cgroup_subsys_state { 


struct cgroup *cgroup; 


So, the overall picture of cgroups related data structure is following: 
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So, the init_cgroup_root fills the cgrp_df1l_root with the default values. The next thing is 
assigning initial css_set tothe init_task which represents first process in the system: 


RCU_INIT_POINTER(init_task.cgroups, &init_css_set); 


And the last big thing in the cgroup_init_early function is initialization of early cgroups . 
Here we go over all registered subsystems and assign unique identity number, name of a 
subsystem and call the cgroup_init_subsys function for subsystems which are marked as 
early: 


for_each_subsys(ss, i) { 
ss->id = i; 


ss->name = cgroup_subsys_name[i]; 


if (ss->early_init) 
cgroup_init_subsys(ss, true); 


The for_each_subsys here is a macro which is defined in the kerne!/cgroup.c source code 
file and just expands to the for loop over cgroup_subsys array. Definition of this array may 
be found in the same source code file and it looks in a little unusual way: 


#define SUBSYS(_x) [_x ## _cgrp_id] = &_x ## _cgrp_subsys, 
static struct cgroup_subsys *cgroup_subsys[] = { 





#include <linux/cgroup_subsys.h> 
J; 
#undef SUBSYS 


It is defined as sussys macro which takes one argument (name of a subsystem) and 
defines cgroup_subsys array of cgroup subsystems. Additionally we may see that the array 
is initialized with content of the linux/cgroup_subsys.h header file. If we will look inside of this 
header file we will see again set of the sussys macros with the given subsystems names: 


#if IS _ENABLED(CONFIG_CPUSETS) 
SUBSYS(cpuset ) 
#endif 


#if IS _ENABLED(CONFIG_CGROUP_SCHED) 
SUBSYS(cpu) 
#endif 


This works because of #undef statement after first definition of the sussys macro. Look at 
the & x ## _cgrp_subsys expression. The ## operator concatenates right and left 
expression ina c macro. So as we passed cpuset , cpu and etc., tothe susBsys macro, 
somewhere cpuset_cgrp_subsys , cp_cgrp_subsys should be defined. And that's true. If you 
will look in the kernel/cpuset.c source code file, you will see this definition: 


struct cgroup_subsys cpuset_cgrp_subsys = { 


.early_init = true, 


}; 


So the last step in the cgroup_init_early function is initialization of early subsystems with 
the call of the cgroup_init_subsys function. Following early subsystems will be initialized: 


@ cpuset ; 
e cpu; 


@ cpuacct . 


The cgroup_init_subsys function does initialization of the given subsystem with the default 
values. For example sets root of hierarchy, allocates space for the given subsystem with the 
call of the css_alloc callback function, link a subsystem with a parent if it exists, add 
allocated subsystem to the initial process and etc. 


That's all. From this moment early subsystems are initialized. 


Conclusion 


It is the end of the first part which describes introduction into control groups mechanism in 
the Linux kernel. We covered some theory and the first steps of initialization of stuffs related 
to control groups mechanism. In the next part we will continue to dive into the more 
practical aspects of control groups . 


If you have any questions or suggestions write me a comment or ping me at twitter. 


Please note that English is not my first language, And | am really sorry for any 
inconvenience. If you find any mistakes please send me a PR to linux-insides. 


Links 


e control groups 
e PID 

e cpuset 

e block devices 
e huge pages 
e sysfs 

e proc 
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e cgroups kernel documentation 
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e docker) 

e perf events) 

e Previous chapter 
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Linux 内 核 概 念 


本 章 描述 内 核 中 使 用 到 的 各 种 各 样 的 概念 。 


e 每 个 CPU 的 变量 

e CPU #43 

e initcall 机 制 

e Linux 内 核 的 通知 链 


亦 号 - 
Per-cpu £ € 
Per-cpu 变量 是 一 项 内 核 特 性 。 从 它 的 名 字 你 就 可 以 理解 这 项 特性 的 意义 了 。 我 们 可 以 创建 一 


个 变量 ， 然 后 每 个 CPU 上 都 会 有 一 个 此 变量 的 拷贝 。 本 节 我 们 来 看 下 这 个 特性 ， 并 试 着 去 理 
解 它 是 如 何 实现 以 及 工作 的 。 


内 核 提供 了 一 个 创建 per-cpu 变量 的 API- DEFINE_PER_CPU 宏 : 


#define DEFINE_PER_CPU(type, name) \ 
DEFINE_PER_CPU_SECTION(type, name, "") 


正如 其 它 许 多 处 理 per-cpu 变量 的 宏一 样 ， 这 个 宏 定 义 在 include/linux/percpu-defs.h 中 。 现 
在 我 们 来 看 下 这 个 特性 是 如 何 实 现 的 。 


看 下 DECLARE_PER_CPU 的 定义 ， 可 以 看 到 它 使 用 了 2 个 参数 : type 和 name ， 因 此 我 们 可 
以 这 样 创 建 per-cpu 变量 : 


DEFINE_PER_CPU(int, per_cpu_n) 


我 们 传 入 要 创建 变量 的 类 型 和 名 字 ， DEFINE_PER CPU 调用 DEFINE PER_CPU_SECTION ， 将 两 个 
参数 和 空 字 符 串 传递 给 后 者 。 让 我 们 来 看 下 DEFINE_PER_CPU_SECTION 的 定义 : 


#define DEFINE_PER_CPU_SECTION(type, name, sec) N 
__PCPU_ATTRS(sec) PER_CPU_DEF_ATTRIBUTES \ 
__typeof__(type) name 


#define __PCPU_ATTRS(sec) \ 
__percpu __attribute__((section(PER_CPU_BASE_SECTION sec))) À 
PER_CPU_ATTRIBUTES 


其 中 section 是 : 


#define PER_CPU_BASE_SECTION ".data..percpu" 


当 所 有 的 宏 展开 之 后 ， 我 们 得 到 一 个 全 局 的 per-cpu 变量 : 


_ attribute ((section(".data..percpu"))) int per_cpu_n 


这 意味 着 我 们 在 .data..percpu 段 有 了 一 个 per_cpu_n 变量 ， 可 以 在 vmlinux 中 找到 它 


.data..percpu 00013a58 0000000000000000 0000000001a5c000 O0e00000 2**12 
CONTENTS, ALLOC, LOAD, DATA 


好 ， 现 在 我 们 知道 了 ， 当 我 们 使 用 DEFINE_PER_CPU 宏 时 ， 一 个 在 .data..percpu 段 中 的 
per-cpu 变量 就 被 创建 了 o 内 核 初始 化 时 ， 人 调用 setup_per_cpu_areas 函数 多 次 加 载 
.data..percpu 段 ， 每 个 CPU 一 次 。 


让 我 们 来 看 下 per-cpu 区 域 初 始 化 流程 。 它 从 init/main.c 中 调用 setup_per_cpu_areas 函数 
开始 ， 这 个 函数 定义 在 arch/x86/kernel/setup_percpu.c 中 。 


pr_info("NR_CPUS:%d nr_cpumask_bits:%d nr_cpu_ids:%d nr_node_ids:%d\n", 
NR_CPUS, nr_cpumask_bits, nr_cpu_ids, nr_node_ids); 


setup_per_cpu_areas 开始 输出 在 内 核 配 置 中 以 conric_nrR_cpus 配置 项 设置 的 最 大 CPUs 
数 ， 实 际 的 CPU 个 数 ， nr_cpumask_bits (对 于 新 的 cpumask 操作 来 说 和 NR_cpus 是 一 样 
的 ) ， 还 有 NUMA 节点 个 数 。 


我 们 可 以 在 dmesg 中 看 到 这 些 输 出 : 


$ dmesg | grep percpu 
[ 0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1 


后 我 们 检查 per-cpu 第 一 个 块 分 配器 。 所 有 的 per-cpu 区 域 都 是 以 块 进行 分 配 的 。 第 一 个 
se 于 静态 per-cpu 变量 。Linux 内 核 提 供 了 决定 第 一 个 块 分 配器 类 型 的 命令 
行 : percpu alloc 。 我 们 可 以 在 内 核 文档 中 读 到 它 的 说 明 。 


percpu_alloc= 选择 要 使 用 哪个 per-cpu 第 一 个 块 分 配器 。 
当前 支持 的 类 型 是 "embed" Fe "page": 
不 同 架构 支持 这 些 类 型 的 子 集 或 不 支持 。 
更 多 分 配器 的 细节 参考 mm/percpu.c 中 的 注释 。 
这 个 参数 主要 是 为 了 调试 和 性 能 比较 的 。 


mm/percpu.c 包含 了 这 个 命令 行 选项 的 处 理 函数 : 


early_param("percpu_alloc", percpu_alloc_setup); 


其 中 percpu_alloc_setup 函数 根据 percpu_alloc 参数 值 设 置 pcpu_chosen_fc Reo Rik 
第 一 个 块 分 配器 是 auto 


enum pcpu_fc pcpu_chosen_fc __initdata = PCPU_FC_AUTO; 


如 果 内 核 命令 行 中 没有 设置 percpu_alloc 参数 ， 就 会 使 用 embed 分 配器 ， 将 第 一 个 per- 
cpu ik AA memblock 的 bootmem。 最 后 一 个 分 配器 和 第 一 个 块 page 分 配器 一 样 ， 只 
是 将 第 一 个 块 使 用 paGE_sIZE 页 进行 了 映射 。 


如 我 上 面 所 写 ， 首 先 我 们 在 setup_per_cpu_areas 中 对 第 一 个 块 分 配器 检查 ， 检 查 到 第 一 个 
块 分 配器 不 是 page 分 配器 


If (pcpu_chosen_fc != PCPU_FC_PAGE) { 


如 果 不 是 PCPU_FC_PAGE ， 我 们 就 使 用 embed 分 配器 并 使 用 pcpu_embed_first_chunk 函数 分 
配 第 一 块 空间 。 


= pcpu_embed_first_chunk(PERCPU_FIRST_CHUNK_RESERVE, 
dyn_size, atom_size, 
pcpu_cpu_distance, 
pcpu_fc_alloc, pcpu_fc_free); 


如 前 所 述 ， 函 数 pcpu_embed_first_chunk 将 第 一 个 per-cpu Rik A bootmen， 因 此 我 们 传递 
一 些 参数 给 pcpu_embed_first_chunk ° 参数 如 下 : 


© PERCPU_FIRST_CHUNK_RESERVE -为 静态 变量 per-cpu 保留 空间 的 大 小 
© dyn size -动态 分 配 的 最 少 空闲 字 节 ; 

e atom size -所 有 的 分 配 都 是 这 个 的 整数 倍 ， 并 以 此 对 齐 ; 

@ pcpu_cpu distance - 决定 cpus 距离 的 回调 函数 ; 

e pcpu fc alloc -分 分 配 percpu 页 的 函数 ; 

e pcpu fc free - 释放 percpu 页 的 函数 。 


在 调用 pcpu_embed_first_chunk 前 我 们 计算 好 所 有 的 参数 : 


const size_t dyn_size = PERCPU_MODULE_RESERVE + PERCPU_DYNAMIC_RESERVE - PERCPU_FIRST_ 
CHUNK_RESERVE; 
size_t atom_size; 
#ifdef CONFIG_X86_64 
atom_size = PMD_SIZE; 
#else 
atom_size = PAGE_SIZE; 
#endif 


如 果 第 一 个 块 分 配器 是 PCPU_FC_PAGE ， 我 们 用 pcpu_page_first_chunk 而 不 是 
pcpu_embed_first_chunk ° per-cpu 区 域 准 备 好 以 后 ， 我 们 用 setup_percpu_segment 函数 设 
置 per-cpu 的 偏 移 和 段 〈 只 针对 x86 系统 ) ， 并 将 前 面 的 数据 从 数组 移 到 per-cpu 变量 


( x86_cpu_to_apicid , irq_stack_ptr 等 等 ) o 当 内 核 完 成 初始 化 进程 后 ， 我 们 就 有 了 N 个 
.data..percpu 段 ， 其 中 N 是 CPU 个 数 ， bootstrap 进程 使 用 的 段 将 会 包含 用 
DEFINE_PER_CPU 宏 创 建 的 未 初始 化 的 变量 。 


内 核 提供 了 操作 per-cpu 变量 的 API : 


e get_cpu_var(var) 
e put cpu var(var) 

让 我 们 来 看 看 get_cpu_var 的 实现 : 
#define get_cpu_var(var) N 
Ga Ñ 

preempt_disable(); \ 


this_cpu_ptr(&var); \ 
})) 


Linux 内 核 是 抢占 式 的 ， 获 取 per-cpu 变量 需要 我 们 知道 内 核 运 行 在 哪个 处 理 器 上 。 因 此 访问 
per-cpu 变量 时 ， 当 前 代码 不 能 被 抢占 ， 不 能 移 到 其 它 的 CPU。 如 我 们 所 见 ， 这 就 是 为 什么 
首先 调用 preempt_disable 函数 然后 调用 this_cpu_ptr 宏 ， 像 这 样 : 


#define this_cpu_ptr(ptr) raw_cpu_ptr(ptr) 
以 及 
#define raw_cpu_ptr(ptr) per_cpu_ptr(ptr, 0) 


per_cpu_ptr 返回 一 个 指向 给 定 CPU (第 2 个 参数 ) per-cpu 变量 的 指针 。 当 我 们 创建 了 一 
个 per-cpu 变量 并 对 其 进行 了 修改 时 ， 我 们 必须 调用 put cpu var Ki BAR 
preempt_enable 使 能 抢占 。 因 此 典型 的 per-cpu 变量 的 使 用 如 下 : 


get_cpu_var (var); 


put_cpu_var (var); 


让 我 们 来 看 下 这 个 per_cpu_ptr 宏 : 


#define per_cpu_ptr(ptr, cpu) 
({ 
verify_pcpu_ptr(ptr); 
SHIFT_PERCPU_PTR((ptr), per_cpu_offset((cpu))); 





Ee T a E A 


}) 


就 像 我 们 上 面 写 的 ， 这 个 宏 返 回 了 一 个 给 定 cpu 的 per-cpu 变量 。 首 先 它 调用 了 


verify_pcpu_ptr 





#define __verify_pcpu_ptr(ptr) 
do { 
const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL; 





(void)__vpp_verify; 
} while (0) 


该 宏 声明 了 ptr 类 型 的 const void __percpu * ° 


之 后 ， 我 们 可 以 看 到 带 两 个 参数 的 SHIFT_PERCPU_PTR 宏 的 调用 。 第 一 个 参数 是 我 们 的 指针 ， 
第 二 个 参数 是 传 给 per_cpu_offset 宏 的 CPU 数 : 


#define per_cpu_offset(x) (__per_cpu_offset[x]) 


GRY x 扩展 为 __per_cpu_offset 数组 : 


extern unsigned long __per_cpu_offset[NR_CPUS]; 


其 中 nricpus 是 CPU 的 数目 。 per cpu_offset 数组 以 CPU 变量 拷贝 之 间 的 距离 填充 。 
例如 ， 所 有 per-cpu 变量 是 x 字 节 大 小 ， 所 以 我 们 通过 __per_cpu_offset[Y] 就 可 以 访问 
xx*Y 。 让 我 们 来 看 下 _ SHIFT_PERCPU_PTR 的 实现 : 


#define SHIFT_PERCPU_PTR(__p, offset) \ 
RELOC_HIDE((typeof(*(__p)) __kernel _ force *)(__p), (__offset)) 





RELOC_HIDE 只 是 取得 偏 移 量 (typeof(ptr)) (ptr + (off)) ， 并 返回 一 个 指向 该 变量 的 指 


针 。 


就 这 些 了 ! 当然 这 不 是 全 部 的 API， 只 是 一 个 大 概 。 开 头 是 比较 艰难 ， 但 是 理解 per-cpu 变量 


RAR EHA include/linux/percpu-defs.h 的 奥秘 。 


让 我 们 再 看 下 获得 per-cpu 变量 指针 的 算法 : 


© 内 核 在 初始 化 流程 中 创建 多 个 .data. .percpu 段 〈 一 个 per-cpu 变量 一 个 ) 3 

e 所 有 DEFINE_PER_CPU 宏 创 建 的 变量 都 将 重新 分 配 到 首 个 扇 区 或 者 CPU0 ; 

e per_cpu_offset 数组 以 ( BooT_PERCPU_OFFSET ) 和 .data..percpu 扇 区 之 间 的 距离 填 
充 ; 

e 当 per_cpu_ptr 被 调用 时 ， 例 如 取 一 个 per-cpu 变量 的 第 三 个 CPU 的 指针 ， 将 访问 
__per_cpu_offset 数组 ， 该 数组 的 索引 指向 了 所 需 CPU 。 


就 这 么 多 了 。 


每 个 CPU 的 变量 
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CPU masks 


cpumasks 是 Linux 内 核 提供 的 保存 系统 CPU 信息 的 特殊 方法 。 包 含 cpumasks 操作 API 相关 
的 源码 和 头 文件 : 


e include/linux/coumask.h 
e lib/cpumask.c 
e kernel/cpu.c 


正如 include/linux/cpumask.h 注释 : Coumasks 提供 了 代表 系统 中 CPU 集合 的 位 图 ， 一 位 放 
置 一 个 CPU Bae 。 我 们 已 经 在 Kernel entry point #82 > BAX poot_cpu_init 中 看 到 了 一 
cpumask。 这 个 函数 将 第 一 个 启动 的 cou 上 线 、 激 活 等 等 ...... 


set_cpu_online(cpu, true); 
set_cpu_active(cpu, true); 
set_cpu_present(cpu, true); 
set_cpu_possible(cpu, true); 


set_cpu_possible 是 一 个 在 系统 启动 时 任意 时 刻 都 可 插入 的 cpu ID 集合 。 cpu_ OE 代表 

了 当前 插入 的 CPUs。 cpu_online 是 cpu_present 的 子 集 ， 表 示 可 调度 的 CPUs。 这 些 掩 码 

ie CONFIG_HOTPLUG_CPU 配置 选项 ， 以 及 possible == present 和 active == online 选 
是 否 被 禁用 。 这 些 函 数 的 实现 很 相似 ， 检 测 第 二 个 参数 ， 如 果 为 true ， 就 调用 


cpumask_set_cpu ， 否则 调用 cpumask_clear_cpu ° 


有 两 种 方法 创建 cpumask ° 第 一 种 是 用 cpumask_t ° 定义 如 下 : 


typedef struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t; 


它 封 装 了 cpumask 结构 ， 其 包含 了 一 个 位 掩 码 pits 字段 。 DECLARE_BITMAP 宏 有 两 个 
数 : 


e bitmap name; 
e number of bits. 


并 以 给 定名 称 创建 了 一 个 unsigned long 数组 。 它 的 实现 非常 简单 : 


#define DECLARE_BITMAP(name,bits) \ 
unsigned long name[BITS_TO_LONGS(bits) ] 


其 中 BITs To_LONGS 


#define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long) ) 


#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) 7 (d)) 


因为 我 们 专注 于 x86 64 架构 ， unsigned long 是 8 字 节 大 小 ， 因 此 我 们 的 数组 仅 包 含 一 个 元 


素 : 


(((8) + (8) - 1) / (8))= 1 


NR_CPUS 宏 表 示 的 是 系统 中 CPU 的 数目 ， 且 依赖 于 在 include/linux/threads.h 中 定义 的 


CONFIG_NR_CPUS 宏 ， 看 起 来 像 这 样 : 


#ifndef CONFIG_NR_CPUS 
#define CONFIG NR_CPUS 1 


#endif 


#define NR_CPUS CONFIG_NR_CPUS 


第 二 种 定义 cpumask 的 方法 是 直接 使 用 宏 DECLARE_BITMAP 和 to_cpumask 宏 ， 后 者 将 给 定 
的 位 图 转化 为 struct cpumask * 


#define to_cpumask(bitmap) \ 


((struct cpumask *)(1 ? (bitmap) \ 
: (void *)sizeof(__check_is_bitmap(bitmap) ))) 


可 以 看 到 这 里 的 三 目 运算 符 每 次 总 是 true ° _ check is bitmap 内 联 函 数 定义 为 : 


static inline int __check_is_bitmap(const unsigned long *bitmap) 


{ 


return 1; 


每 次 都 是 返回 1 。 我 们 需要 它 只 是 因为 : 编译 时 检测 一 个 给 定 的 bitmap 是 一 个 位 图 ， 换 勾 
话说 ， 它 检测 一 个 bitmap 是 否 有 unsigned long * 类 型 。 因 此 我 们 传递 


cpu_possible_bits 给 宏 to_cpumask ， 将 unsigned long 数组 转换 为 ”struct cpumask * ° 


cpumask API 


因为 我 们 可 以 用 其 中 一 个 方法 来 定义 cpumask ’ Linux 内 核 提 供 了 API 来 处 理 coumask ° HK 
们 来 研究 下 其 中 一 个 函数 ， 例 如 set_cpu_online ， 这 个 函数 有 两 个 参数 : 


e CPU 数目 ; 
e CPU 状态 ; 


这 个 函数 的 实现 如 下 所 示 : 


void set_cpu_online(unsigned int cpu, bool online) 


{ 
if (online) { 
cpumask_set_cpu(cpu, to_cpumask(cpu_online_bits)); 
cpumask_set_cpu(cpu, to_cpumask(cpu_active_bits)); 
} else { 
cpumask_clear_cpu(cpu, to_cpumask(cpu_online_bits)); 
} 
} 


该 函数 首先 检测 第 二 个 state 参数 并 调用 依赖 它 的 cpumask_set_cpu 或 


cpumask_clear_cpu 。 这 里 我 们 可 以 看 到 在 中 cpumask_set_cpu 的 第 二 个 参数 转换 为 struct 
cpumask * 。 在 我 们 的 例子 中 是 位 图 cpu_online_bits ， 定 义 如 下 : 


static DECLARE_BITMAP(cpu_online_bits, CONFIG_NR_CPUS) read_mostly; 





函数 cpumask_set_cpu 仅 调 用 了 一 次 set_bit BA: 


static inline void cpumask_set_cpu(unsigned int cpu, 


{ 


struct cpumask *dstp) 


set_bit(cpumask_check(cpu), cpumask_bits(dstp)); 


set_bit 函数 也 有 两 个 参数 ， 设 置 了 一 个 给 定位 〈 第 一 个 参数 ) 的 内 存 (第 二 个 参数 或 
cpu_online_bits 位 图 ) 。 这 儿 我 们 可 以 看 到 在 调用 set_bit 之 前 ， 它 的 两 个 参数 会 传递 给 


e cpumask_check; 
e cpumask_bits. 


让 我 们 细 看 下 这 两 个 宏 。 第 一 个 cpumask_check 在 我 们 的 例子 里 没 做 任何 事 ， 只 是 返回 了 给 
的 参数 。 第 二 个 cpumask_bits 只 是 返回 了 传 入 struct cpumask * 结构 的 bits 域 。 


#define cpumask_bits(maskp) ((maskp)->bits) 


现在 让 我 们 看 下 set bit 的 实现 : 


static __always_inline void 
set_bit(long nr, volatile unsigned long *addr) 
{ 
if (IS_IMMEDIATE(nr)) { 
asm volatile(LOCK_PREFIX "orb %1,%0" 
: CONST_MASK_ADDR(nr, addr) 
"ig" ((u8)CONST_MASK(nr)) 
: "memory"); 
} else { 
asm volatile(LOCK_PREFIX "bts %1,%0" 
: BITOP_ADDR(addr) : "Ir" (nr) : "memory"); 


这 个 函数 看 着 吓人 ， 但 它 没 有 看 起 来 那么 难 。 首 先 传 参 nr 或 者 说 位 数 给 1S_IMMEDIATE 
宏 ， 该 宏 调用 了 GCC AK BAR __builtin_constant_p 


#define IS_IMMEDIATE(nr) (__builtin_constant_p(nr) ) 


__builtin_constant_p 检查 给 定 参 数 是 否 编译 时 恒定 变量 。 因 为 我 们 的 cpu 不 是 编译 时 恒 
变量 ， 将 会 执行 else 分 支 : 


六 | 


asm volatile(LOCK_PREFIX "bts %1,%0" : BITOP_ADDR(addr) : "Ir" (nr) : "memory"); 


让 我 们 试 着 一 步 一 步 来 理解 它 如 何 工 作 的 : 


LOCK_PREFIX 是 个 x86 lock 指令 。 这 个 指令 告诉 CPU 当 指 令 执 行 时 占据 系统 总 线 。 这 允许 
CPU 同步 内 存 访问 ， 防 止 多 核 (或 多 设备 - 比如 DMA 控制 器 ) 并 发 访问 同一 个 内 存 cell 。 
BITOP_ADDR 转换 给 定 参数 至 (*(volatile long *) 并 且 加 了 m 约束 。 + 意味 着 这 个 操作 
数 对 于 指令 是 可 读 写 的 。m 显示 这 是 一 个 内 存 操作 数 。 BITOP_ADDR ee 


#define BITOP_ADDR(x) "+m" (*(volatile long *) (x)) 


接 下 来 是 memory 。 它 告诉 编译 器 汇编 代码 执行 内 存 读 或 写 到 某 些 项 ， 而 不 是 那些 输入 或 输出 
操作 数 ( 例 如， 访问 指向 输出 参数 的 内 存 ) © 
Ir -寄存 器 操作 数 。 


bts 指令 设置 一 个 位 字符 串 的 给 定位 ， 存 储 给 定位 的 值 到 cF 标志 位 。 所 以 我 们 传递 Cpu 
号 ， 我 们 的 例子 中 为 0， 给 set_bit 并 且 执 行 后 ， 其 设置 了 在 cpu_online_bits cpumask 中 
的 0 位 。 这 意味 着 第 一 个 cpu 此 时 上 线 了 。 


当然 ， 除 了 set_cpu_* API 外 ，cpumask 提供 了 其 它 cpumasks 操作 的 API。 让 我 们 简短 看 
Fe 


附加 的 cpumask API 


cpumaks 提供 了 一 系列 宏 来 得 到 不 同 状 态 CPUs 序号 。 例 如 : 


#define num_online_cpus() cpumask_weight(cpu_online_mask) 


这 个 宏 返 回 了 online CPUs 数量 。 它 读 取 cpu_online_mask 位 图 并 调用 了 cpumask_weight 
函数 。 cpumask_weight 函数 使 用 两 个 参数 调用 了 一 次 bitmap_weight 函数 : 


e cpumask bitmap; 
e nr_cpumask_bits -在 我 们 的 例子 中 就 是 NR_CPUS ° 


static inline unsigned int cpumask weight(const struct cpumask *srcp) 
{ 


return bitmap_weight(cpumask_bits(srcp), nr_cpumask_bits); 


并 计算 给 定位 图 的 位 数 。 除 了 num_online_cpus ， cpumask 还 提供 了 所 有 CPU KANE : 


e num_possible_cpus; 
e num_active_cpus; 
e cpu_online; 

e cpu_possible. 


KE KE 


FFO 
除了 Linux 内 核 提供 的 下 述 操作 cpumask 的 API: 


e for_each_cpu - 遍历 一 个 mask 的 所 有 cpu; 

e for_each_cpu_not - 遍历 所 有 补 集 的 CPU， 

e cpumask_clear_cpu - 清除 一 个 cpumask 的 cpu; 

@ cpumask test cpu - 测试 一 个 mask 中 的 Cpu; 

e cpumask_setall -设置 mask 的 所 有 cpu; 

© cpumask_size - 返回 分 配 'struct cpumask' 字 节 数 大 小 ; 


还 有 很 多 。 


pEi 
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initcall 机 制 


介绍 
就 像 你 从 标题 所 理解 的 ， 分 将 涉及 Linux 内 核 中 有 趣 且 重要 的 概念 ， 称 之 为 initcall 。 


在 Linux 内 核 中 ， n 类 似 这 样 的 定义 : 


early_param("debug", debug_kernel); 


或 者 


arch_initcall(init_pit_clocksource); 


在 我 们 分 析 这 个 机 制 在 内 核 中 是 如 何 实现 的 之 前 ， 我 们 必须 了 解 这 个 机 制 是 什么 oe 
Linux 内 核 中 是 如 何 使 用 它 的 。 像 这 样 的 定义 表示 一 个 回调 函数 ， 它 们 会 在 Linux 内 核 局 
中 或 启动 后 调用 。 实 际 上 initcall 机 制 的 要 点 是 确定 内 oh be rete 
序 。 举 个 例子 ， 我 们 来 看 看 下 面 的 函数 : 


static int _ init nmi_warning_debugfs(void) 


{ 
debugfs_create_u64("nmi_longest_ns", 0644, 


arch_debugfs_dir, &nmi_longest_ns); 


return 0: 


个 函数 出 自 源码 文件 arch/x86/kernel/nmi.c。 我 们 可 以 看 到 ， 这 个 函数 只 是 在 
arch_debugfs_dir 目录 中 创建 nmi_longest_ns debugfs 文件 。 实 际 上 ， 只 有 在 
arch_debugfs_dir 创建 后 ， 才 会 创建 这 个 debugfs 文件 。 这 个 目录 是 在 Linux 内 核 特 定 架 构 
的 初始 化 期 间 创 建 的 。 实 际 上 ， 该 目录 将 在 源码 文件 arch/x86/kernel/kdebugfs.c 的 
arch_kdebugfs_init 函数 中 创建 ° 注意 arch_kdebugfs_init KRU BKARIZA initcall ° 


arch_initcall(arch_kdebugfs_init); 


Linux 内 核 在 调用 fs 相关 的 initcalls 之 前 调用 所 有 特定 架构 的 initcalls 。 因 此 ， 只 有 
在 arch_kdebugfs_dir 目录 创建 以 后 才 会 创建 我 们 的 nmi_longest_ns ° IRE > Linux 内 核 
提供 了 八 个 级 别 的 主 initcalls : 


e early ; 


@ core ; 


@ postcore ; 


e arch; 
@ susys ; 
© Biss; 


e device ; 


© late. 


它们 的 所 有 名 称 是 由 数组 initcall level names 来 描述 的 ， 该 数组 定义 在 源码 文件 
init/main.c 中 : 


static char *initcall_level_names[] _ initdata = { 
"early", 
“corel, 
"postcore", 
Melee 
"subsys", 
Sr 
"device", 
"late", 


}; 
所 有 用 这 些 标识 符 标 记 为 initcall 的 函数 将 会 以 相同 的 顺序 被 调用 ， 或 者 说 ， early 


initcalls 会 首先 被 调用 ， 其 次 是 core initcalls ， 以 此 类 推 。 现 在 ， 我 们 对 initcall 机 
制 了 解 点 了 ， 所 以 我 们 可 以 开始 潜入 Linux 内 核 源码 ， 来 看 看 这 个 机 制 是 如 何 实现 的 。 


initcall 机 制 在 Linux 内 核 中 的 实现 


Linux 内 核 提 供 了 一 组 来 自 头 文件 include/linux/init.h 的 宏 ， 来 标记 给 定 的 函数 为 initcall ° 
所 有 这 些 宏 都 相当 简单 : 


#define early_initcall(fn) __define_initcall(fn, early) 
#define core_initcall(fn) __define_initcall(fn, 1) 
#define postcore_initcall(fn) __define_initcall(fn, 2) 
#define arch_initcall(fn) __define_initcall(fn, 3) 
#define subsys_initcall(fn) __define_initcall(fn, 4) 
#define fs_initcall(fn) __define_initcall(fn, 5) 
#define device_initcall(fn) __define_initcall(fn, 6) 
#define late_initcall(fn) __define_initcall(fn, 7) 


我 们 可 以 看 到 > 这 些 宏 只 是 从 同一 个 头 文件 的 __define_initcall 宏 的 调用 扩展 而 来 此 
外 ，_define_initcall 宏 有 两 个 参数 : 


e fn -在 调用 某 个 级 别 initcalls 时 调用 的 回调 函数 ; 
e id -识别 initcall 的 标识 符 ， 用 来 防止 两 个 相同 的 initcalls 指向 同一 个 处 理 函 数 


时 出 现 错误 。 


__define_initcall 宏 的 实现 如 下 所 示 : 


#define _ define initcall(fn, id) \ 
static initcall_t _ initcall ##fn##id _ used \ 
”attribute ((_ section (".initcall" #id ".init"))) = fn; \ 
LTO_REFERENCE_INITCALL(__initcall_##fn##1id) 


要 了 解 define_initcall 宏 ， 首 先 让 我 们 来 看 下 initcall t 类 型 。 这 个 类 型 定义 在 同一 
个 头 文 件 中 ， 它 表示 一 个 返回 整形 指针 的 函数 指针 ， 这 将 是 initcall 的 结果 : 


typedef int (*initcall_t)(void); 


现在 让 我 们 回 到 _-define_initcall X ° HE RA TARANEE o ERM BF 

> _ define_initcall 宏 的 第 一 行 产 生 了 .initcall id .init ELF 部 分 给 定 函 数 的 定义 ， 
并 标记 以 下 gcc 属性 : __initcall_function_name_id 和 _ used 。 如 果 我 们 查看 表示 内 核 链 
接 脚本 数据 的 include/asm-generic/vmlinux.lds.h 头 文件 ， 我 们 会 看 到 所 有 的 initcalls 部 

分 都 将 放 在 .data H: 


#define INIT_CALLS \ 
VMLINUX_SYMBOL(__initcall_start) = .; \ 
*(,initcallearly.init) \ 
INIT_CALLS_LEVEL(0) 

INIT_CALLS_LEVEL(1) 

INIT_CALLS_LEVEL(2) 

INIT_CALLS_LEVEL(3) 

INIT_CALLS_LEVEL(4) 

INIT_CALLS_LEVEL(5) 
INIT_CALLS_LEVEL(rootfs) \ 
INIT_CALLS_LEVEL(6) \ 
INIT_CALLS_LEVEL(7) \ 
VMLINUX_SYMBOL(__initcall_end) = .; 


Cee ee A 


#define INIT_DATA_SECTION(initsetup_align) N 
.init.data : AT(ADDR(.init.data) - LOAD_OFFSET) { \ 


INIT_CALLS \ 


第 二 个 属性 - _used ， 定 义 在 include/linux/compiler-gcc.h 头 文件 中 ， 它 扩展 了 以 下 gce 
定 


#define _ used __attribute__((__used_)) 


它 防 止 定义 了 变量 但 未 使 用 的 告警 。 宏 _ define initcall 最 后 一 行 是 : 


LTO_REFERENCE_INITCALL(__initcall_##fn##id) 


这 取决 于 coNFIG_LTO 内 核 配 置 选 项 ， 只 为 编译 器 提供 链接 时 间 优 化 存根 : 


#ifdef CONFIG_LTO 
#define LTO_REFERENCE_INITCALL(x) \ 
static _ used __exit void *reference_##x(void) \ 


{ \ 
return &x; \ 
} 
#else 
#define LTO_REFERENCE_INITCALL(x) 
#endif 


为 了 防止 当 模 块 中 的 变量 没有 引用 时 而 产生 的 任何 问题 ， 它 被 移 到 了 程序 末尾 。 这 就 是 关于 
__define_initcall 宏 的 全 部 了 。 所 以 ， 所 有 的 * initcall 宏 将 会 在 Linux 内 核 编译 时 扩 
展 ， 所 有 的 initcalls 会 放置 在 它们 的 段 内 ， 并 可 以 通过 data 段 来 获取 ，Linux 内 核 在 初 
始 化 过 程 中 就 知道 在 哪儿 去 找到 initcall 并 调用 它 。 

PLEX Linux 内 核 可 以 调用 initcalls ， 我 们 就 来 看 下 Linux 内 核 是 如 何 做 的 。 这 个 过 程 从 


init/main.c 头 文件 的 do_basic_setup 函数 开始 : 


static void Minit do_basic_setup(void) 


{ 


do_initcalls(); 


该 函数 在 Linux 内 核 初 始 化 过 程 中 调用 ， 调 用 时 机 是 主要 的 初始 化 步骤 ， 比 如 内 存 管 理 器 相 
关 的 初始 化 、 CPU 子 系统 等 完成 之 后 o do_initcalls HAA 是 遍历 SEE 级 别 数组 ， 
并 调用 每 个 级 别 的 do_initcall_level 3: 


static void init do_initcalls(void) 


{ 
int level; 
for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++) 
do_initcall_level(level); 
} 


initcall_levels 数组 在 同一 个 源码 文件 中 定义 ， 和 包含 了 定义 在 _ define initcall KPA 
那些 段 的 指针 : 


static initcall_t *initcall_levels[] __initdata = { 

__initcallO_start, 
__initcalli_start, 
__initcall2_start, 
__initcall3_start, 
__initcall4_start, 
__initcall5_start, 
__initcall6_start, 
__initcall7_start, 
__initcall_end, 


}; 


如 果 你 有 兴趣 ， 你 可 以 在 Linux 内 核 编译 后 生成 的 链接 器 脚本 arch/x86/kernel/vmlinux. lds 
中 找到 这 些 段 : 


.init.data : AT(ADDR(.init.data) - Oxffffffff80000000) { 


__initcall_start = .; 
*(,initcallearly.init) 
__initcallO_start = .; 
*(,initcallO.init) 
*(,initcallOs.init) 
__initcalli_start = .; 


如 果 你 对 这 些 不 熟 ， 可 以 在 本 书 的 菜 些 部 分 了 解 更 多 关于 链接 器 的 信息 。 


正如 我 们 刚 看 到 的 ，do_initcall level 函数 有 一 个 参数 - initcall 的 级 别 ， 做 了 以 下 两 件 
事 : 首先 这 个 函数 拷贝 了 initcall commandline ， 这 是 通常 内 核 包 含 了 各 个 模块 参数 的 命令 
行 的 副本 ， 并 用 kernel/params.c 源 码 文件 的 parse_args 函数 解析 它 ， 然 后 调用 各 个 级 别 的 


do_on_initcall Ha: 


for (fn = initcall_levels[level]; fn < initcall_levels[level+i]; fn++) 
do_one_initcall(*fn); 


do_on_initcall 为 我 们 做 了 主要 的 工作 。 我 们 可 以 看 到 ， 这 个 函数 有 一 个 参数 表示 
initcall 回调 函数 ， 并 调用 给 定 的 回调 函数 : 


int Minit or module do_one_initcall(initcall_t fn) 


{ 

int count = preempt_count(); 

ine Get 

char msgbuf[64]; 

if (initcall_blacklisted(fn) ) 
return -EPERM; 

if (initcall_debug) 
ret = do_one_initcall_debug(fn); 

else 
ret = fn(); 

msgbuf[0] = 0; 

if (preempt_count() != count) { 
sprintf(msgbuf, "preemption imbalance "); 
preempt_count_set(count); 

} 

if (irdqs disabled()) { 
stricat(msgbuf, "disabled interrupts ", sizeof(msgbuf)); 
local_irq_enable(); 

} 

WARN(msgbuf[0], "initcall %pF returned with %s\n", fn, msgbuf); 

return ret; 

} 


让 我 们 来 试 着 理解 do_on_initcall 函数 做 了 什么 。 首 先 我 们 增加 preemption 计数 ， 以 便 我 
们 稍 后 进行 检查 ， 确 保 它 不 是 不 平衡 的 。 这 步 以 后 ， 我 们 可 以 看 到 initcall backlist 函数 
的 调用 ， 这 个 函数 遍历 包含 了 initcalls 黑 名 单 的 blacklisted_initcalls 链表 ， 如 果 
initcall 在 黑 名 单 里 就 释放 它 : 


list_for_each_entry(entry, &blacklisted_initcalls, next) { 
if (!stremp(fn_name, entry->buf)) { 
pr_debug("initcall %s blacklisted\n", fn_name); 
kfree(fn_name); 
return true; 


黑 名 单 的 initcalls 保存 在 blacklisted initcalls 链表 中 ， 这 个 链表 是 在 早期 Linux AK 
初始 化 时 由 Linux 内 核 命 令 行 来 填充 的 。 


处 理 完 进入 黑 名 单 的 initcalls ， 接 下 来 的 代码 直接 调用 initcall 


if (initcall debug) 

ret = do_one_initcall debug(fn); 
elise 

ret = fn(); 


取决 于 initcall_debug 变量 的 值 ， do_one_initcall_debug 函数 将 调用 initcall ， 或 直接 
调用 fn) ° initcall _ debug 变量 定义 在 同一 个 源码 文件 : 


bool initcall_debug; 


该 变量 提供 了 向 内 核 日 志 缓 冲 ies ee ” 能 力 。 可 以 通过 initcall_debug 参数 从 内 核 
命令 行 中 设置 这 个 变量 的 值 。 从 Linux 内 核 命令 行文 档 可 以 看 到 : 


=> 


initcall_debug [KNL] Trace initcalls as they are executed. Useful 
for working out where the kernel is dying during 
startup. 


确实 如 此 。 如 果 我 们 看 下 do_one_initcall_debug 函数 的 实现 ， 我 们 会 看 到 它 与 
do_one_initcall 函数 做 了 一 样 的 事 2 也 就 是 说 ” do_one_initcall_debug LEOP 了 给 定 的 
initcall ， 并 打印 了 一 些 和 initcall 相关 的 信息 (比如 当前 任务 的 pid、 initcall 的 持续 

时 间 等 ) 


static int __init_or_module do_one_initcall_debug(initcall_t fn) 
{ 

ktime_t calltime, delta, rettime; 

unsigned long long duration; 

int ret; 


printk(KERN_DEBUG "calling %pF @ %i\n", fn, task_pid_nr(current)); 

calltime = ktime_get(); 

ret = fn(); 

rettime = ktime_get(); 

delta = ktime_sub(rettime, calltime); 

duration = (unsigned long long) ktime_to_ns(delta) >> 10; 

printk(KERN_DEBUG "initcall %pF returned %d after %lld usecs\n", 
fn, ret, duration); 


return ret; 


由 于 initcall 被 do_one_initcall 或 do_one_initcall_debug 调用 ， 我 们 可 以 看 到 在 
do_one_initcall 哆 数 末 尾 做 了 两 次 检查 。 第 一 个 检查 在 initcall 执 行内 部 
__preempt_count_add 和 __preempt_count_sub 可 能 的 执行 次 数 ， 如 果 这 个 值 和 之 前 的 可 抢占 
计数 不 相等 ， 我 们 就 把 preemption imbalance 字符 串 添 加 到 消息 缓冲 区 ， 并 设置 正确 的 可 抢 
占 计 数 : 


if (preempt_count() != count) { 
sprintf(msgbuf, "preemption imbalance "); 
preempt_count_set(count); 


稍 后 这 个 错误 字符 串 就 会 被 打印 出 来 。 最 后 检查 本 地 IRQs 的 状态 ， 如 果 它 们 被 禁用 了 ， 我 们 
就 将 disabled interrupts 字符 串 添 加 到 我 们 的 消息 缓冲 区 ， 并 为 当前 处 理 器 使 能 IRQs ， 
以 防 出 现 IRs 被 initcall 禁用 了 但 不 再 使 能 的 情况 出 现 : 


if (irqs_disabled()) { 
stricat(msgbuf, "disabled interrupts ", sizeof(msgbuf)); 
local_irq_enable(); 


这 就 是 全 部 了 。 通 过 这 种 方式 ，LinuXx 内 核 以 正确 的 顺序 完成 了 很 多 子 系统 的 初始 化 。 现 在 我 
们 知道 Linux 内 核 的 initcall 机 制 是 怎么 回 事 了 。 在 这 部 分 中 ， 我 们 介绍 了 initcall 机 
制 的 主要 部 分 ， 但 遗留 了 一 些 重要 的 概念 。 让 我 们 来 简单 看 下 这 些 概念 。 


首先 ， 我 们 错过 了 一 个 级 别 的 initcalls ， 就 是 rootfs initcalls 。 和 我 们 在 本 部 分 看 到 的 
很 多 宏 类 似 ， 你 可 以 在 includellinux/init.h 头 文件 中 找到 rootfs_initcall 的 定义 : 


#define rootfs initcall(fn) __define_initcall(fn, rootfs) 


从 这 个 宏 的 名 字 我 们 可 以 理解 到 ， 它 的 主要 目的 是 保存 和 rootfs 相关 的 回调 。 除 此 之 外 ， 只 
有 在 与 设备 相关 的 东西 没 被 初始 化 时 ， 在 文件 系统 级 别 初始 化 以 后 再 初始 化 一 些 其 它 东西 时 
才 有 有 用。 例如， 发 生 在 源码 文件 initinitramfs.c 中 populate_rootfs 函数 里 的 解压 initramfs : 


rootfs_initcall(populate_rootfs); 


在 这 里 ， 我 们 可 以 看 到 熟悉 的 输出 : 


[ 0.199960] Unpacking initramfs... 


除了 rootfs_initcall 级 别 ， 还 有 其 它 的 console initcall ` security_initcall 和 其 他 辅 
助 的 initcall 级 别 。 我 们 遗漏 的 最 后 一 件 事 ， 是 *_initcall sync 级 别 的 集合 。 在 这 部 分 
我 们 看 到 的 几乎 每 个 * initcall 宏 ， 都 有 _sync 前 级 的 宏 伴随 : 


#define core_initcall_sync(fn) __define_initcall(fn, 1s) 
#define postcore_initcall_sync(fn) __define_initcall(fn, 2s) 
#define arch_initcall_sync(fn) __define_initcall(fn, 3s) 
#define subsys_initcall_sync(fn) __define_initcall(fn, 4s) 
#define fs_initcall_sync(fn) __define_initcall(fn, 5s) 
#define device_initcall_sync(fn) __define_initcall(fn, 6s) 
#define late_initcall_sync(fn) __define_initcall(fn, 7s) 


这 些 附 加 级 别 的 主要 目的 是 ， 等 待 所 有 某 个 级 别 的 与 模块 相关 的 初始 化 例 程 完 成 。 


在 这 部 分 中 ， 我 们 看 到 了 Linux 内 核 的 一 项 重要 机 制 ， 即 在 初始 化 期 间 人 允许 调 用 依赖 于 Linux 
内 核 当 前 状态 的 函数 。 


如 果 你 有 问题 或 建议 ， 可 随时 在 twitter 0xAX 上 联系 我 ， 给 我 发 email， 或 者 创建 issue 。 


请 注意 英语 不 是 我 的 母语 ， 对 此 带 来 的 不 便 ， 我 很 抱歉 。 如 果 你 发 现 了 任何 错误 ， 都 可 以 给 
我 发 PR 到 linux-insides。. 
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Notification Chains in Linux Kernel 


Introduction 


The Linux kernel is huge piece of C) code which consists from many different subsystems. 
Each subsystem has its own purpose which is independent of other subsystems. But often 
one subsystem wants to know something from other subsystem(s). There is special 
mechanism in the Linux kernel which allows to solve this problem partly. The name of this 
mechanism is - notification chains and its main purpose to provide a way for different 
subsystems to subscribe on asynchronous events from other subsystems. Note that this 
mechanism is only for communication inside kernel, but there are other mechanisms for 
communication between kernel and userspace. 


Before we will consider notification chains API and implementation of this API, let's look 
at Notification chains mechanism from theoretical side as we did it in other parts of this 
book. Everything which is related to notification chains mechanism is located in the 
include/linux/notifier.h header file and kernel/notifier.c source code file. So let's open them 
and start to dive. 


Notification Chains related data structures 


Let's start to consider notification chains mechanism from related data structures. As | 
wrote above, main data structures should be located in the include/linux/notifier.h header file, 
so the Linux kernel provides generic API which does not depend on certain architecture. In 
general, the notification chains mechanism represents a list (that's why it named 

chains ) of callback) functions which are will be executed when an event will be occurred. 


All of these callback functions are represented as notifier_fn_t type in the Linux kernel: 


typedef i (*notifier_fn_t)(struct notifier_block *nb, unsigned long action, void 
*data); 


So we may see that it takes three following arguments: 


e nb -is linked list of function pointers (will see it now); 

e action -is type of an event. A notification chain may support multiple events, so we 
need this parameter to distinguish an event from other events; 

e data -is storage for private information. Actually it allows to provide additional data 


information about an event. 


Additionally we may see that notifier_fn_t returns an integer value. This integer value 
maybe one of: 


e NOTIFY_DONE - Subscriber does not interested in notification; 

e NOTIFY_OK -notification was processed correctly; 

e NOTIFY_BAD - Something went wrong; 

e NOTIFY_STOoP -notification is done, but no further callbacks should be called for this 
event. 


All of these results defined as macros in the include/linux/notifier.h header file: 


#define NOTIFY_DONE 0x0000 

#define NOTIFY_OK 0x0001 

#define NOTIFY_BAD (NOTIFY_STOP_MASK | 0x0002) 
#define NOTIFY_STOP (NOTIFY_OK|NOTIFY_STOP_MASK) 


Where NoTIFY_sToP_MASK represented by the: 


#define NOTIFY_STOP_MASK 0x8000 


macro and means that callbacks will not be called during next notifications. 


Each part of the Linux kernel which wants to be notified on a certain event will should 
provide own notifier_fn_t Callback function. Main role of the notification chains 
mechanism is to call certain callbacks when an asynchronous event occurred. 


The main building block of the notification chains mechanism is the notifier_block 
structure: 


struct notifier_block { 
notifier_fn_t notifier_call; 
struct notifier_block _ rcu *next; 
int priority; 


}; 


which is defined in the include/linux/notifier.h file. This struct contains pointer to callback 
function - notifier_call , link to the next notification callback and priority of a callback 
function as functions with higher priority are executed first. 


The Linux kernel provides notification chains of four following types: 


e Blocking notifier chains; 
e SRCU notifier chains; 


e Atomic notifier chains; 
e Raw notifier chains. 


Let's consider all of these types of notification chains by order: 


In the first case for the blocking notifier chains , callbacks will be called/executed in 
process context. This means that the calls in a notification chain may be blocked. 


The second srcu notifier chains represent alternative form of blocking notifier chains . 
In the first case, blocking notifier chains uses rw_semaphore synchronization primitive to 
protect chain links. srcu notifier chains run in process context too, but uses special form of 
RCU mechanism which is permissible to block in an read-side critical section. 


In the third case for the atomic notifier chains runs in interrupt or atomic context and 
protected by spinlock synchronization primitive. The last raw notifier chains provides 
special type of notifier chains without any locking restrictions on callbacks. This means that 
protection rests on the shoulders of caller side. It is very useful when we want to protect our 
chain with very specific locking mechanism. 


If we will look at the implementation of the notifier_block structure, we will see that it 
contains pointer to the next element from a notification chain list, but we have no head. 
Actually a head of such list is in separate structure depends on type of a notification chain. 
For example for the blocking notifier chains : 


struct blocking_notifier_head { 
struct rw_semaphore rwsem; 
struct notifier_block _ rcu *head; 


}; 


or for atomic notification chains : 


struct atomic_notifier_head { 
spinlock_t lock; 
struct notifier_block _ rcu *head; 


}; 


Now as we know alittle about notification chains mechanism let's consider 
implementation of its API. 


Notification Chains 


Usually there are two sides in a publish/subscriber mechanisms. One side who wants to get 
notifications and other side(s) who generates these notifications. We will consider 
notification chains mechanism from both sides. We will consider blocking notification 
chains in this part, because of other types of notification chains are similar to it and differs 
mostly in protection mechanisms. 


Before a notification producer is able to produce notification, first of all it should initialize 
head of a notification chain. For example let's consider notification chains related to kernel 
loadable modules. If we will look in the kernel/module.c source code file, we will see 
following definition: 


static BLOCKING_NOTIFIER_HEAD(module_notify_list); 


which defines head for loadable modules blocking notifier chain. The 
BLOCKING_NOTIFIER_HEAD macro is defined in the include/linux/notifier.n header file and 
expands to the following code: 


#define BLOCKING_INIT_NOTIFIER_HEAD(name) do { Ñ 


init_rwsem(&(name)->rwsem); \ 
(name) ->head = NULL; X 
} while (0) 


So we may see that it takes name of a name of a head of a blocking notifier chain and 
initializes read/write semaphore and set head to NULL . Besides the 
BLOCKING_INIT_NOTIFIER_HEAD macro, the Linux kernel additionally provides 
ATOMIC_INIT_NOTIFIER_HEAD , RAW_INIT_NOTIFIER_HEAD Macros and srcu_init_notifier 
function for initialization atomic and other types of notification chains. 


After initialization of a head of a notification chain, a subsystem which wants to receive 
notification from the given notification chain it should register with certain function which is 
depends on type of notification. If you will look in the include/linux/notifier.n header file, you 
will see following four function for this: 


extern int atomic_notifier_chain_register(struct atomic_notifier_head *nh, 
struct notifier_block *nb); 


extern int blocking_notifier_chain_register(struct blocking_notifier_head *nh, 


struct notifier_block *nb); 


extern int raw_notifier_chain_register(struct raw_notifier_head *nh, 
struct notifier_block *nb); 


extern int srcu_notifier_chain_register(struct srcu_notifier_head *nh, 
struct notifier_block *nb); 


As | already wrote above, we will cover only blocking notification chains in the part, so let's 

consider implementation of the blocking_notifier_chain_register function. Implementation 

of this function is located in the kernel/notifier.c source code file and as we may see the 
blocking_notifier_chain_register takes two parameters: 


e nh -head of a notification chain; 
e nb -notification descriptor. 


Now let's look at the implementation of the blocking_notifier_chain_register function: 


int raw_notifier_chain_register(struct raw_notifier_head *nh, 
struct notifier_block *n) 
{ 
return notifier_chain_register(&nh->head, n); 
} 


As we may see it just returns result of the notifier_chain_register function from the same 
source code file and as we may understand this function does all job for us. Definition of the 
notifier_chain_register function looks: 


int blocking_notifier_chain_register(struct blocking_notifier_head *nh, 
struct notifier_block *n) 
{ 
Int Get; 
if (unlikely(system_state == SYSTEM _BOOTING) ) 
return notifier_chain_register(&nh->head, n); 
down_write(&nh->rwsem) ; 
ret = notifier_chain_register(&nh->head, n); 
up_write(&nh->rwsem) ; 
return ret; 
} 


As we may see implementation of the blocking_notifier_chain_register is pretty simple. 
First of all there is check which check current system state and if a system in rebooting state 
we just call the notifier_chain_register . In other way we do the same call of the 
notifier_chain_register but as you may see this call is protected with read/write 
semaphores. Now let's look at the implementation of the notifier_chain_register function: 


static int notifier_chain_register(struct notifier_block Sni, 
struct notifier_block *n) 


while ((*n1) != NULL) { 
if (n->priority > (*n1l)->priority) 
break; 
nl = &((*n1)->next); 
} 
n->next = *nl; 
rcu_assign_pointer(*nl, n); 
(ee Wiel o; 


This function just inserts new notifier_block (given by a subsystem which wants to get 
notifications) to the notification chain list. Besides subscribing on an event, subscriber may 
unsubscribe from a certain events with the set of unsubscribe functions: 


extern int atomic_notifier_chain_unregister(struct atomic_notifier_head *nh, 
struct notifier_block *nb); 


extern int blocking_notifier_chain_unregister(struct blocking_notifier_head *nh, 
struct notifier_block *nb); 


extern int raw_notifier_chain_unregister(struct raw_notifier_head *nh, 
Stnuctinotahrer block nb); 


extern int srcu_notifier_chain_unregister(struct srcu_notifier_head *nh, 
struct notifier_block *nb); 


When a producer of notifications wants to notify subscribers about an event, the 
* notifier_call_chain function will be called. As you already may guess each type of 
notification chains provides own function to produce notification: 


extern int atomic_notifier_call_chain(struct atomic_notifier_head *nh, 
unsigned long val, void *v); 


extern int blocking_notifier_call_chain(struct blocking_notifier_head *nh, 
unsigned long val, void *v); 


extern int raw_notifier_call_chain(struct raw_notifier_head *nh, 
unsigned long val, void *v); 


extern int srcu_notifier_call_chain(struct srcu_notifier_head *nh, 


unsigned long val, void *v); 


Let's consider implementation of the blocking_notifier_call_chain function. This function is 
defined in the kerne!/notifier.c source code file: 


int blocking_notifier_call_chain(struct blocking_notifier_head *nh, 
unsigned long val, void *v) 


return __blocking_notifier_call_chain(nh, val, v, -1, NULL); 


and as we may see it just returns result of the __blocking_notifier_call_chain function. As 
we may see, the blocking_notifer_call_chain takes three parameters: 


e nh - head of notification chain list; 
e val -type of a notification; 
e v -input parameter which may be used by handlers. 


But the _ blocking_notifier_call_chain function takes five parameters: 


int __blocking_notifier_call_chain(struct blocking_notifier_head *nh, 
unsigned long val, void *v, 
int nr_to_call, int *nr_calls) 


Where nr_to_call and nr_calls are number of notifier functions to be called and number 
of sent notifications. As you may guess the main goal of the _ blocking_notifer_call_chain 
function and other functions for other notification types is to call callback function when an 
event occurred. Implementation of the _ blocking notifier call chain is pretty simple, it 
just calls the notifier_call_chain function from the same source code file protected with 
read/write semaphore: 


int __blocking_notifier_call_chain(struct blocking_notifier_head *nh, 
unsigned long val, void *v, 
int nr_to_call, int *nr_calls) 


int ret = NOTIFY_DONE; 


if (rcu_access_pointer(nh->head)) { 
down_read(&nh->rwsem) ; 
ret = notifier_call_chain(&nh->head, val, v, nr_to_call, 
nr_calls); 
up_read(&nh->rwsem); 


} 


return ret; 


and returns its result. In this case all job is done by the notifier_call_chain function. Main 
purpose of this function informs registered notifiers about an asynchronous event: 


static int notifier_call_chain(struct notifier block **nl, 
unsigned long val, void *v, 
ine mo conca tiant na 


ret = nb->notifier_call(nb, val, v); 


return ret; 


That's all. In generall all looks pretty simple. 


Now let's consider on a simple example related to loadable modules. If we will look in the 
kernel/module.c. As we already saw in this part, there is: 


static BLOCKING_NOTIFIER_HEAD(module_notify_list); 


definition of the module_notify_list in the kernel/module.c source code file. This definition 
determines head of list of blocking notifier chains related to kernel modules. There are at 
least three following events: 


e MODULE_STATE_LIVE 
e MODULE_STATE_COMING 
e MODULE_STATE_GOING 


in which maybe interested some subsystems of the Linux kernel. For example tracing of 
kernel modules states. Instead of direct call of the atomic_notifier_chain_register , 

blocking_notifier_chain_register and etc., most notification chains come with a set of 
wrappers used to register to them. Registatrion on these modules events is going with the 
help of such wrapper: 


int register_module_notifier(struct notifier_block *nb) 


return blocking_notifier_chain_register(&module_notify_list, nb); 


If we will look in the kernel/tracepoint.c source code file, we will see such registration during 
initialization of tracepoints: 


static _ init int init_tracepoints(void) 


{ 
int ret; 
ret = register_module_notifier(&tracepoint_module_nb); 
if (ret) 
pr_warn("Failed to register tracepoint module enter notifier\n"); 
return ret; 
} 


Where tracepoint_module_nb provides callback function: 


static struct notifier_block tracepoint_module_nb = { 
.notifier_call = tracepoint_module_notify, 
.priority = 0, 


}; 


When one of the MODULE_STATE_LIVE , MODULE_STATE_COMING Or MODULE_STATE_GOING events 
occurred. For example the MoDULE_STATE_LIVE the MODULE_STATE_comING notifications will be 
sent during execution of the init_module system call. Or for example mopULE_STATE_GOING 
will be sent during execution of the delete_module system call : 


SYSCALL_DEFINE2(delete_module, const char __user *, name_user, 
unsigned int, flags) 


blocking_notifier_call_chain(&module_notify_list, 
MODULE_STATE_GOING, mod); 


Thus when one of these system call will be called from userspace, the Linux kernel will send 
certain notification depends on a system call and the tracepoint_module_notify callback 
function will be called. 


That's all. 
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Linux 内 核对 很 多 数据 结构 提供 不 同 的 实现 方法 ， 比 如 ， 双 向 链表 ，B+ 树 ， 具 有 优先 级 的 堆 等 
等 。 
这 部 分 考虑 这 些 数据 结构 和 算法 。 

e 双向 链表 

e 位 数组 


Linux 内 核 里 的 数据 结构 一 一 双向 链表 


双向 链表 


Linux 内 核 自 己 实现 了 双向 链表 ， 可 以 在 include/linuxllist.h 找到 定义 。 我 们 将 会 从 双向 链表 
数据 结构 开始 内 核 的 数据 结构 。 为 什么 ? 因为 它 在 内 核 里 使 用 的 很 广泛 ， 你 只 需要 在 free- 
electrons.com 检索 一 下 就 知道 了 。 


首先 让 我 们 看 一 下 在 include/linux/types.h 里 的 主 结构 体 : 


struct list_head { 
struct list_head *next, *prev; 


你 可 能 注意 到 这 和 你 以 前 见 过 的 双向 链表 的 实现 方法 是 不 同 的 。 举 个 例子 来 说 ， 在 glib 库 里 


struct GList { 
gpointer data; 
GList *next; 
GList *prev; 


}; 


通常 来 说 一 个 链表 会 包含 一 个 指向 某 个 项 目的 指针 。 但 是 内 核 的 实现 并 没有 这 样 做 。 所 以 问 
MAT : 链表 在 哪里 保存 数据 呢 ? 。 实际 上 内 核 里 实现 的 链表 实际 上 是 侵入 式 链表 。 侵 入 式 链表 并 
不 在 节点 内 保存 数据 -节点 仅仅 包含 指向 前 后 节点 的 指针 ， 然 后 把 数据 是 附加 到 链表 的 。 这 就 
使 得 这 个 数据 结构 是 通用 的 ， 使 用 起 来 就 不 需要 考虑 节点 数据 的 类 型 了 。 


比如 : 


struct nmi_desc { 
spinlock_t lock; 
struct list_head head; 


}; 


让 我 们 看 几 个 例子 来 理解 一 下 在 内 核 里 是 如 何 使 用 1ist_head 的 。 如 上 所 述 ， 在 内 核 里 有 实 
在 很 多 不 同 的 地 方 用 到 了 链表 。 我 们 以 杂项 字符 驱动 为 例 来 说 明 双 向 链表 的 使 用 。 在 
drivers/char/misc.c 的 杂项 字符 驱动 API 被 用 来 编写 处 理 小 型 硬件 和 虚拟 设备 的 小 驱动 。 这 些 
驱动 共享 相同 的 主 设备 号 : 


#define MISC_MAJOR 10 


但 是 都 有 各 自 不 同 的 次 设备 号 。 比 如 : 


ls -l /dev | grep 10 


Crw------- 1 root root 10, 235 Mar 21 12:01 autofs 
drwxr-xr-x 10 root root 200 Mar 21 12:01 cpu 

Crw------- 1 root root 10, 62 Mar 21 12:01 cpu_dma_latency 
Crw------- 1 root root 10, 203 Mar 21 12:01 cuse 

drwxr-xr-x 2 root root 100 Mar 21 12:01 dri 

Crw-rw-rw- 1 root root 10, 229 Mar 21 12:01 fuse 

CWS EEEE 1 root root 10, 228 Mar 21 12:01 hpet 

Crw------- 1 root root 10，183 Mar 21 12:01 hwrng 
Crw-rw----+ 1 root kvm 10, 232 Mar 21 12:01 kvm 

Crw-rw---- 1 root disk 10, 237 Mar 21 12:01 loop-control 
Crw------- 1 root root 10, 227 Mar 21 12:01 mcelog 
Crw------- 1 root root 10, 59 Mar 21 12:01 memory_bandwidth 
Crw------- 1 root root 10, 61 Mar 21 12:01 network_latency 
Crw------- 1 root root 10, 60 Mar 21 12:01 network_throughput 
Crw-r----- 1 root kmem 10, 144 Mar 21 12:01 nvram 

brw-rw---- 1 root disk 1, 10 Mar 21 12:01 ram10 

Crw--w---- 1 root tty 4, 10 Mar 21 12:01 tty10 

Crw-rw- --- 1 root dialout 4, 74 Mar 21 12:01 ttyS10 
Crw------- 1 root root 10, 63 Mar 21 12:01 vga_arbiter 
Crw------- 1 root root 10, 137 Mar 21 12:01 vhci 


现在 让 我 们 看 看 它 是 如 何 使 用 链表 的 。 首 先 看 一 下 结构 体 miscdevice 


struct miscdevice 
{ 
int minor; 
const char *name; 
const struct file_operations *fops; 
struct list_head list; 
struct device *parent; 
struct device *this_device; 
const char *nodename; 
mode_t mode; 


}; 


我 们 可 以 看 到 结构 体 的 第 四 个 变量 list 是 所 有 注册 过 的 设备 的 链表 。 在 源 代码 文件 的 开始 
可 以 看 到 这 个 链表 的 定义 : 


static LIST_HEAD(misc_list); 


它 扩 展开 来 实际 上 就 是 定义 了 一 个 list head 类 型 的 变量 : 


#define LIST_HEAD(name) \ 
struct list_head name = LIST_HEAD_INIT(name) 


然后 使 用 宏 LIST_HEAD_INIT 进行 初始 化 ， 这 会 使 用 变量 name 的 地 址 来 填充 prev 和 


next 结构 体 的 两 个 变量 。 

#define LIST_HEAD_INIT(name) { &(name), &(name) } 
现在 来 看 看 注册 杂项 设备 的 函数 misc_register 。 它 在 开始 就 用 INIT_LIST_HEAD 初始 化 
了 miscdevice->list ° 


INIT_LIST_HEAD(&misc->list); 


作用 和 宏 LIST _HEAD_INIT 一 样 。 


static inline void INIT_LIST_HEAD(struct list_head *list) 


{ 
list->next = list; 
list->prev = list; 


下 一 步 在 函数 device create 创建 了 设备 后 我 们 就 用 下 面 的 语 名 将 设备 添加 到 设备 链表 : 


list_add(&misc->list, &misc_list); 


内 核 文件 list.h 提供 了 向 链表 添加 新 项 的 接口 函数 。 我 们 来 看 看 它 的 实现 : 


static inline void list_add(struct list_head *new, struct list_head *head) 


{ 


__list_add(new, head, head->next); 


实际 上 就 是 使 用 3 个 指定 的 参数 来 调用 了 内 部 函数 _ list _aad 


e new - 新 项 。 
e head - 新 项 将 会 被 添加 到 head 之 后 . 
e head->next- head 之 后 的 项 。 


_list_add 的 实现 非常 简单 : 


static inline void __list_add(struct list_head *new, 
struct list_head *prev, 
struct list_head *next) 


{ 
next->prev = new; 
new->next = next; 
new->prev = prev; 
prev->next = new; 
} 


我 们 会 在 prev 和 next 之 间 添 加 一 个 新 项 。 所 以 我 们 用 宏 LIST_HEAD_INIT 定义 的 misc 
链表 会 包含 指向 miscdevice->list 的 向 前 指针 和 向 后 指针 g 


这 里 仍 有 一 个 问题 : 如 何 得 到 列表 的 内 容 呢 ? 这 里 有 一 个 特殊 的 宏 : 


#define list_entry(ptr, type, member) \ 
container_of(ptr, type, member) 


使 用 了 三 个 参数 : 


e ptr - 指向 链表 头 的 指针 ; 
e type - 结构 体 类 型 ; 
e member- 在 结构 体内 类 型 为 list head 的 变量 的 名 字 ; 


比如 说 : 


const struct miscdevice *p = list_entry(v, struct miscdevice, list) 
然后 我 们 就 可 以 使 用 p->minor 或 者 p->name 来 访问 miscdevice 。 让 我 们 来 看 看 
list_entry 的 实现 : 


#define list_entry(ptr, type, member) \ 
container_of(ptr, type, member) 


如 我 们 所 见 ， 它 仅仅 使 用 相同 的 参数 调用 了 宏 container_of 。 初 看 这 个 宏 挺 奇怪 的 : 


#define container_of(ptr, type, member) ({ N 
const typeof( ((type *)0)->member ) *_mptr = (ptr); \ 
(type *)( (char *) mptr - offsetof(type,member) );}) 


首先 你 可 以 注意 到 花 括 号 内 包含 两 个 表达 式 。 编 译 器 会 执行 花 括 号 内 的 全 部 语 多 ， 然 后 返回 
最 后 的 表达 式 的 值 。 


举 个 例子 来 说 : 


#include <stdio.h> 


int main() { 
int i = 0; 
printf("i = %d\n", ({++i; ++i;})); 
return 0; 


最 终 会 打印 2 


下 一 点 就 是 typeof , 它 也 很 简单 。 就 如 你 从 名 字 所 理解 的 ， 它 仅仅 返回 了 给 定 变 量 的 类 型 。 
当 我 第 一 次 看 到 宏 containerof 的 实现 时 ， 让 我 觉得 最 奇怪 的 就 是 container of 中 的 0。 
实际 上 这 个 指针 巧妙 的 计算 了 从 结构 体 特定 变量 的 偏 移 ， 这 里 的 6 刚好 就 是 位 宽 里 的 零 偏 
移 。 让 我 们 看 一 个 简单 的 例子 


#include <stdio.h> 


struct s { 
int field1; 
char field2; 
char field3; 
J; 


int main() { 
printf ("%p\n", &((struct s*)0)->field3) ; 
return 0; 


结果 显示 0x5 ° 


下 一 个 宏 offsetof 会 计算 从 结构 体 的 某 个 变量 的 相对 于 结构 体 起 始 地 址 的 偏 移 。 它 的 实现 
和 上 面 类 似 : 


#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER) 


现在 我 们 来 总 结 一 下 宏 containerof 。 只 需要 知道 结构 体 里 面 类 型 为 list_head 的 变量 的 

名 字 和 结构 体 容器 的 类 型 ， 它 可 以 通过 结构 体 的 变量 list_head 获得 结构 体 的 起 始 地 址 。 在 

宏 定 义 的 第 一 行 ， 声 明了 一 个 指向 结构 体 成 员 变量 ptr 的 指针 mt ? 并 且 把 ptr 的 地 

LEME Eo HE bee T _mptr 指向 了 同一 个 地 址 。 从 技术 上 讲 我 们 并 不 需要 这 一 行 ， 但 

是 它 可 以 方便 的 进行 类 型 检查 。 第 一 行 保证 了 特定 的 结构 体 (参数 type) 包含 成 员 变 量 
member 。 第 二 行 代码 会 用 宏 offsetof 计算 成 员 变 量 相对 于 结构 体 起 始 地 址 的 偏 移 ， 然 后 从 
结构 体 的 地 址 减 去 这 个 偏 移 ， 最 后 就 得 到 了 结构 体 的 起 始 地 址 。 


当然 了 list add 和 list_entry 不 是 <linux/list.h> 提供 的 唯一 函数 。 双 向 链表 的 实现 还 
提供 了 如 下 API : 


e list add 

e list_add_tail 

e list_del 

e list_replace 

e list move 

e list_is_last 

e list empty 

e list_cut_position 
e list_splice 

e list_for_each 

e list_for_each_entry 


等 等 很 多 其 它 API 。 


Linux 内 核 中 的 数据 结构 


基数 树 


正如 你 所 知道 的 Linux 内 核 通 过 许多 不 同 库 以 及 函数 提供 各 种 数据 结构 以 及 算法 实现 。 这 个 
部 分 我 们 将 介绍 其 中 一 个 数据 结构 Radix tree ° Linux 内 核 中 有 两 个 文件 与 radix tree 的 实 
现 和 API 相 关 : 


e include/linux/radix-tree.h 
e lib/radix-tree.c 


首先 说 明 一 下 什么 是 radix tree ° Radixtree 是 一 种 压缩 trie > HY trie 是 一 种 通过 保存 


关联 数组 (associative array) 来 提供 关键 字 - 值 (key-value) “存储 与 查找 的 数据 结构 。 通 常 
关键 字 是 字符 串 ， 不 过 也 可 以 是 其 他 数据 类 型 。 


trie 结构 的 节点 与 n-tree 不 同 其 节 点 中 并 不 存储 关键 字 取而代之 的 是 存储 单个 字符 标 
签 。 关 键 字 查找 时 ， 通 过 从 树 的 根 开始 遍历 关键 字 相 关 的 所 有 字符 标签 节点 ， 直 至 到 达 最 终 


的 叶子 节点 。 下 面 是 个 例子 : 


De E + 
| | 
| | 
下 十 testes Weeeee + 
| | | | 
| g | | c | 
| | | | 
站 十 Ps + 
| | 
| | 
Honna Voonana + 让 WW + 
| | | | 
| 0 | | a | 
| | | | 
ae + 人 十 
| 
| 
Teee Vesece + 
| | 
| t | 
| | 
站 十 


这 个 例子 中 ， 我 们 可 以 看 到 trie 所 存储 的 关键 字 信 息 go 5 cat ， 压 缩 trie 或 radix 
tree 与 trie 所 不 同 的 是 ， 所 有 只 存在 单个 孩子 的 中 间 节 点 将 被 压缩 。 


Linux 内 核 中 的 Radix 树 将 值 映 射 为 整 型 关键 字 ，Radix 的 数据 结构 定义 在 
include/linux/radix-tree.h 文件 中 : 


struct radix_tree_root { 


unsigned int height; 
gfp_t gfp_mask; 
struct radix_tree_node rcu *rnode; 





}; 


上 面 这 个 是 radix 树 的 root 节点 的 结构 体 ， 它 包括 三 个 成 员 : 


e height - 从 叶 节 点 向 上 计算 出 的 树 高 度 。 
e gfp_mask -内 存 分 配 标识 。 
e rnode - 子 节点 指针 。 


这 里 我 们 先 讨论 的 结构 体 成 员 是 gfp_mask : 


Lin 
为 


ux ee e E Zi (flag) - gfp mask ， 用 于 描述 内 存 申 请 的 行 
。 这 个 以 6FP ”前 组 开头 的 内 存 申 请 控制 标识 主要 包括 ， GFP_NoI0 禁止 所 有 IO 操作 但 人 允 


许 睡 眠 等 待 内 存 ， _GFP_HIGHMEM ieee 内 核 的 高 端 内 存 ， GFP_ATOMIC 高 优先 级 申请 内 存 
且 操 作 不 允许 被 睡眠 。 


接 下 来 说 的 结构 体 成 员 是 rnode : 


struct radix_tree_node { 


unsigned int path; 
unsigned int count; 
union { 

struct { 


struct radix_tree_node *parent; 
void *private_data; 
}; 
struct rcu_head rcu_head; 
3; 
/* For tree user =y 
struct list_head private_list; 
void _ rcu *slots[RADIX_TREE_MAP_SIZE]; 
unsigned long tags [RADIX_TREE_MAX_TAGS] [RADIX_TREE_TAG_LONGS]; 


}; 


这 个 结构 体 中 包括 这 几 个 内 容 ， 节 点 与 父 节点 的 偏 移 以 及 到 树 底 端 的 高 度 ， 子 节点 的 个 数 ， 
节点 的 存储 数据 域 ， 具 体 描述 如 下 : 


path -从 叶 节 点 

count - 子 节点 的 个 数 。 

parent - 父 节点 的 指针 。 

private_data - 存储 数据 ARAFE ° 
rcu_head - 用 于 节点 释放 的 RCU 链 表 。 
private_list - 存储 数据 ° 


结构 体 radix_tree_node 的 最 后 两 个 成 员 tags 4 slots 是 非常 重要 且 需 要 特别 注意 的 
每 个 Radix 树 节点 都 可 以 包括 一 个 指向 存储 数据 指针 的 slots 集合 ， 空 闲 slots 的 指针 指向 
NULL ° Linux 内 核 的 Radix 树 结构 体 中 还 包含 用 于 记录 节点 存储 状态 的 标签 tags 成 员 ， 标 
签 通过 位 设置 指示 Radix 树 的 数据 存储 状态 。 


至 此 ， 我 们 了 解 到 radix 树 的 结构 ， 接 下 来 看 一 下 radix 树 所 提供 的 API 。 


Linux 内 核 基 数 树 API 


我 们 从 数据 结构 的 初始 化 开始 看 ，radix 树 支 持 两 种 方式 初始 化 。 


第 一 个 是 使 用 宏 RADIX_TREE 


RADIX_TREE(name, gfp_mask); 


正如 你 看 到 ， 只 需要 提供 name 参数 ， 就 能 够 使 用 RaDIX TREE 宏 完 成 radix 的 定义 以 及 初始 
化 ， RADIX_TREE 宏 的 实现 非常 简单 : 


#define RADIX_TREE(name, mask) \ 
struct radix_tree_root name = RADIX_TREE_INIT(mask) 


#define RADIX_TREE_INIT(mask) { 
-height = 0, 
.gfp_mask = (mask), 
.rnode = NULL, 


RADIX_TREE 宏 首 先 使 用 name 定义 了 一 个 radix_tree_root 实例 并 用 RaDIX_TREE_INIT KX 
带 参数 mask 进行 初始 化 。 宏 RADIX_TREE_INIT 将 radix_tree_root 初始 化 为 默认 属性 并 将 
gfp_mask 初始 化 为 入 参 mask 。 第 二 种 方式 是 手工 定义 radix tree root 变量 ， 之 后 再 使 
用 mask 调用 INIT_RADIX_TREE 宏 对 变量 进行 初始 化 。 


struct radix_tree_root my_radix_tree; 
INIT_RADIX_TREE(my_tree, gfp_mask_for_my_radix_tree); 





INIT RADIX TREE 宏 定义 : 


#define INIT_RADIX_TREE(root, mask) 
do { 


(root)->gfp_mask = (mask); 
(root)->rnode = NULL; 
} while (0) 


\ 
X 
(root)->height = 0; \ 
N 
\ 


宏 INIT_RADIX_TREE 所 初始 化 的 属性 与 RADIX_TREE_INIT 一 致 
接 下 来 是 radix 树 的 节点 插入 以 及 删除 ， 这 两 个 函数 : 


@ radix_tree_insert ; 


© radix_tree_delete . 
第 一 个 函数 radix tree_insert 需要 三 个 入 参 : 


e radix 树 root 节点 结构 
e@ 索引 关键 字 
e 需要 插入 存储 的 数据 


第 二 个 函数 radix_tree delete 除了 不 需要 存储 数据 参数 外 4 其 他 与 radix_tree_insert 一 
Ro 


radix 树 的 查找 实现 有 以 下 几 个 函数 : The search in a radix tree implemented in two ways: 


e radix_tree_lookup ; 
e radix_tree_gang_lookup ; 


@ radix_tree_lookup_slot . 
第 一 个 函数 radix_tree_lookup 需要 两 个 参数 : 


e radix 树 root 节点 结构 
e 索引 关键 字 


这 个 函数 通过 给 定 的 关键 字 查找 radix 树 ， 并 返 关 键 字 所 对 应 的 结 点 。 


第 二 个 函数 radix_tree_gang_lookup 具有 以 下 特征 : 


unsigned int radix_tree_gang_lookup(struct radix tree root *root, 
void **results, 
unsigned long first_index, 
unsigned int max_items); 


函数 返回 查找 到 记录 的 条 目 数 ， 并 根据 关键 字 进 行 排序 ， 返 回 的 总 结 点 数 不 超过 入 参 


max_items 的 大 小 。 


最 后 一 个 函数 radix_tree_lookup_slot 返回 结 点 slot 中 所 存储 的 数据 。 


pEi 


e Radix tree 
e Trie 


Linux 内 核 里 的 数据 结构 一 一 位 数组 


Linux 内 核 中 的 位 数组 和 位 操作 


除了 不 同 的 基于 链 式 和 树 的 数据 结构 以 外 ，Linux 内 核 也 为 位 数组 (或 称 为 位 图 (bitmap) ) 
提供 了 API。 位 数组 在 Linux 内 核 里 被 广泛 使 用 ， 并 且 在 以 下 的 源 代 码 文件 中 包含 了 与 这 样 的 
结构 搭配 使 用 的 通用 API : 


e lib/bitmap.c 
e include/linux/bitmap.h 


除了 这 两 个 文件 之 外 ， 还 有 体系 结构 特定 的 头 文件 ， 它 们 为 特定 的 体系 结构 提供 优化 的 位 操 
作 。 我 们 将 探讨 x86 64 体系 结构 ， 因 此 在 我 们 的 例子 里 ， 它 会 是 


e arch/x86/include/asm/bitops.h 


头 文件 。 正 如 我 上 面 所 写 的 ， 仓 图 在 Linux 内 核 中 被 广泛 地 使 用 。 例 如 ， 位 数组 常常 用 于 保 
存 一 组 在 线 /离线 处 理 器 ， 以 便 系 统 支持 热 插 拔 的 CPU (你 可 以 在 cpumasks 部 分 阅读 更 多 相 
关 知 识 ) ， 一 个 位 数组 (bit array) 可 以 在 Linux 内 核 初 始 化 等 期 间 保 存 一 组 已 分 配 的 中 断 处 
F o 


因此 ， 本 部 分 的 主要 目的 是 了 解 位 数组 (bit array) 是 如 何在 Linux 内 核 中 实现 的 。 让 我 们 现 
在 开始 吧 。 


位 数组 声明 


在 我 们 开始 查看 位 图 操作 的 API 之 前 ， 我 们 必须 知道 如 何在 Linux 内 核 中 声明 它 。 有 两 种 
声明 位 数组 的 通用 方法 。 第 一 种 简单 的 声明 一 个 位 数组 的 方法 是 ， 定 义 一 个 unsigned long 
的 数组 ， 例 如 : 


unsigned long my_bitmap[8] 


第 二 种 方法 ， 是 使 用 DECLARE_BITMAP 宏 ， 它 定义 于 include/linux/types.h 头 文 件 : 


#define DECLARE_BITMAP(name,bits) \ 
unsigned long name[BITS_TO_LONGS(bits) ] 


我 们 可 以 看 到 DECLARE_BITMAP 宏 使 用 两 个 参数 : 


© name -位 图 名 称 ; 
e bits -位 图 中 位 数 ; 


并 且 只 是 使 用 BITS_TO_LONGS(bits) 元 素 展开 unsigned long 数组 的 定义 。 BITS_TO_LONGS 
宏 将 一 个 给 定 的 位 数 转换 为 long 的 个 数 ， 换 言 之 ， 就 是 计算 bits 中 有 多 少 个 8 字 节 元 
素 : 


#define BITS_PER_BYTE 8 
#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) 
#define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long) ) 


因此 ， 例 如 DECLARE_BITMAP(my_bitmap, 64) 将 产生 : 


>>> (((64) + (64) - 1) / (64)) 
al 


5: 


unsigned long my_bitmap[1]; 


在 能 够 声明 一 个 位 数组 之 后 ， 我 们 便 可 以 使 用 它 了 。 


体系 结构 特定 的 位 操作 


我 们 已 经 看 了 上 面 提 及 的 一 对 源 文 件 和 头 文件 ， 它 们 提供 了 位 数组 操作 的 API。 其 中 重要 且 广 
泛 使 用 的 位 数组 API 是 体系 结构 特定 的 且 位 于 已 提 及 的 头 文 件 中 
arch/x86/include/asm/bitops.h ° 


首先 让 我 们 查看 两 个 最 重要 的 函数 : 


© set bit ; 


© clear_bit . 


我 认为 没有 必要 解释 这 些 函 ee 。 从 它们 的 名 字 来 看 ， 这 已 经 很 清楚 了 。 让 我 们 直接 查 
看 它们 的 实现 。 如 果 你 浏览 arch/x86/include/asm/bitops.h 头 文件 ， 你 将 会 注意 到 这 些 函 数 中 
的 每 一 个 都 有 原子 性 和 非 原子 性 两 种 变 体 。 在 我 们 开始 深入 这 些 函 数 的 实现 之 前 ， 首 先 ， 我 
们 必须 了 解 一 些 有 关 原 子 (atomic) 操作 的 知识 。 


简 而 言 之 ， 原 子 操作 保证 两 个 或 以 上 的 操作 不 会 并 发 地 执行 同一 数据 。 x86 体系 结构 提供 了 
一 系列 原子 指令 ， 例 如 ，xchg、cmpxchg 等 指令 。 除 了 原子 指令 ， 一 些 非 原子 指令 可 以 在 
lock 指令 的 帮助 下 具有 原子 性 。 现 在 你 已 经 对 原子 操作 有 了 足够 的 了 解 ， 我 们 可 以 接着 探讨 
set_bit 和 clear_bit Aa LM o 


我 们 先 考 虑 函数 的 非 原子 性 (non-atomic) 变 体 。 非 原子 性 的 set_bit 和 clear_bit 的 名 
字 以 双 下 划 线 开始 。 正 如 我 们 所 知道 的 ， 所 有 这 些 函数 都 定义 于 
arch/x86/include/asm/bitops.h 头 文 件 ， 并 且 第 一 个 函数 就 是 _ set_bit : 


static inline void __set_bit(long nr, volatile unsigned long *addr) 


{ 
asm volatile("bts %1,%0" : ADDR : "Ir" (nr) : "memory"); 


} 


正如 我 们 所 看 到 的 ， 它 使 用 了 两 个 参数 : 


e nr -位 数组 中 的 位 号 (LCTT 译注 : 从 0 开始 ) 
e addr -我 们 需要 置 位 的 位 数组 地 址 


EB? addr 参数 使 用 volatile 关键 字 定 义 ， 以 告诉 编译 器 给 定 地 址 指向 的 变量 可 能 会 被 
修改 。 _set_bit 的 实现 相当 简单 。 正 如 我 们 所 看 到 的 ， 它 仅 包含 一 行内 联 汇 编 代码 。 在 我 
们 的 例子 中 ， 我 们 使 用 bts 指令 ， 从 位 数组 中 选 出 一 个 第 一 操作 数 (我 们 的 例子 中 的 nr ) 
所 指定 的 位 ， 存 储 选 出 的 位 的 值 到 CF 标志 寄存 器 并 设置 该 位 (LCTT 译注 : BP nr 指定 的 
位 置 为 1) 。 


注意 ， 我 们 了 解 了 nr 的 用 法 ， 但 这 里 还 有 一 个 参数 adar 呢 1 你 或 许 已 经 猜 到 秘密 就 在 
ADDR ° ADDR 是 一 个 定义 在 同一 个 头 文 件 中 的 宏 ， 它 展开 为 一 个 包含 给 定 地 址 和 tm 约束 
的 字符 串 : 


#define ADDR BITOP_ADDR(addr ) 
#define BITOP_ADDR(x) "+m" (*(volatile long *) (x)) 


除了 m 之 外 ， 在 _set_bit 函数 中 我 们 可 以 看 到 其 他 约束 。 让 我 们 查看 并 试 着 理解 它们 所 
表示 的 意义 : 


e im -表示 内 存 操作 数 ， 这 里 的 + 表明 给 定 的 操作 数 为 输入 输出 操作 数 ; 

。 1 -表示 整 型 常量 ; 

© r -表示 寄存 器 操作 数 
除了 这 些 约束 之 外 ， 我 们 也 能 看 到 memory 关键 字 ， 其 告诉 编译 器 这 上 段 代 码 会 修改 内 存 中 的 
变量 。 到 此 为 止 ， 现 在 我 们 看 看 相同 的 原子 性 (atomic) 变 体 函 数 。 它 看 起 来 比 非 原子 性 
(non-atomic) 变 体 更 加 复杂 : 


static _ always_inline void 
set_bit(long nr, volatile unsigned long *addr) 


{ 
if (IS_IMMEDIATE(nr)) { 
asm volatile(LOCK_PREFIX "orb %1,%0" 
: CONST_MASK_ADDR(nr, addr) 
: "ig" ((u8)CONST_MASK(nr)) 
: "memory"); 
} else { 
asm volatile(LOCK_PREFIX "bts %1,%0" 
: BITOP_ADDR(addr) : "Ir" (nr) : "memory"); 
} 
} 


(LCTT 译注 : BITOP_ADDR 的 定义 为 : #define BITOP_ADDR(x) "=m" (*(volatile long *) 
(x)) ? ORB 为 字 节 按 位 或 。) 
首先 注意 ， 这 个 函数 使 用 了 与 _set_bit 相同 的 参数 集合 ， 但 额外 地 使 用 了 

always_inline 属性 标记 。 _ always_inline 是 一 个 定义 于 include/linux/compiler-gcc.h 的 


宏 ， 并 且 只 是 展开 为 always_inline 属性 : 


#define _ always_inline inline __attribute_ ((always_inline) ) 


其 意味 着 这 个 函数 总 是 内 联 的 ， 以 减少 Linux 内 核 映像 的 大 小 。 现 在 让 我 们 试 着 了 解 下 


set_bit HAKI RI o KARTE set_bit 函数 的 开头 检查 给 定 的 位 的 数 
量 。 IS IMMEDIATE 宏 定 义 于 相同 的 头 文 件 ， 并 展开 为 gcc 内 置 函 数 的 调用 : 


#define IS_IMMEDIATE(nr) (__builtin_constant_p(nr) ) 


如 果 给 定 的 参数 是 编译 期 已 知 的 常量 ， builtin constant p 内 置 函 数 则 返回 1 ， 其 他 情况 
返回 6。 假若 给 定 的 位 数 是 编译 期 已 知 的 常量 ， 我 们 便 无 须 使 用 效率 低下 的 bts 指令 去 设 
置 位 。 我 们 可 以 只 需 在 给 定 地 址 指向 的 字 节 上 执行 按 位 或 操作 ， 其 字 节 包含 给 定 的 位 ， 掩 码 
位 数 表 示 高 位 为 1 ， 其 他 位 为 0 的 掩 码 。 在 其 他 情况 下 ， 如 果 给 定 的 位 号 不 是 编译 期 已 知 常 
量 ， 我 们 便 做 和 _set_bit 远 数 一 样 的 事 。 CONST_MASK_ADDR 宏 : 


#define CONST_MASK_ADDR(nr, addr) BITOP_ADDR((void *)(addr) + ((nr)>>3)) 


展开 为 带 有 到 包含 给 定位 的 字 节 偏 移 的 给 定 地 址 ， 例 如 ， 我 们 拥有 地 址 ox19000 和 位 号 
0x9 ° AA oxo 代表 一 个 字 节 + 一 位 ， 所 以 我 们 的 地 址 是 addr +1: 


>>> hex(0x1000 + (0x9 >> 3)) 
"@x1001' 


CONST_MASK 宏 将 我 们 给 定 的 位 号 表示 为 字 节 ， 位 号 对 应 位 为 高 位 1 ， 其 他 位 为 @ : 


#define CONST_MASK(nr) (1 << ((nr) & 7)) 


>>> bin(1 << (0x9 & 7)) 
SODIL 


最 后 ， 我 们 应 用 按 位 或 运算 到 这 些 变量 上 上面， 因此， 假如 我 们 的 地 址 是 gx4697 ， 并 且 我 们 
需要 置 位 号 为 9 的 位 为 1 


>>> bin(0x4097) 

"@b100000010010111' 

>>> bin((0x4097 >> 0x9) | (1 << (0x9 & 7))) 
"@b100010' 


第 9 位 将 会 被 置 位 。 (LCTT 译注 : 这 里 的 9 是 从 0 开始 计数 的 ， 比 如 0010， 按 照 作者 的 
意思 ， 其 中 的 1 是 第 1 位 ) 


注意 ， 所 有 这 些 操作 使 用 Lock_PREFIX 标记 ， 其 展开 为 lock 指令 ， 保 证 该 操作 的 原子 性 。 


正如 我 们 所 知 ， 除 了 set_bit 和 _ set_bit 操作 之 外 ，Linux 内 核 还 提供 了 两 个 功能 相反 的 
函数 ， 在 原子 性 和 非 原 子 性 的 上 下 文中 清 位 。 它 们 是 clear_bit 和 _clear_bit 。 这 两 个 函 
数 都 定义 于 同一 个 头 文件 并 且 使 用 相同 的 参数 集合 。 不 仅 参数 相似 ， 一 般 而 言 ， 这 些 函数 与 
set_bit 和 _set_bit 也 非常 相似 。 让 我 们 查看 非 原 子 性 _clear_bit 的 实现 吧 : 


static inline void __clear_bit(long nr, volatile unsigned long *addr) 


{ 
asm volatile("btr %1,%0" : ADDR : "Ir" (nr)); 


} 


没 错 ， 正 如 我 们 所 见 ，_clear_bit 使 用 相同 的 参数 集合 ， 并 包含 极其 相似 的 内 联 汇 编 代码 
块 。 它 只 是 使 用 btr 指令 替换 了 bts 。 正 如 我 们 从 函数 名 所 理解 的 一 样 ， 通 过 给 定 地 址 ， 它 
清除 了 给 定 的 位 。 ptr 指令 表现 得 像 bts (LCTT 译注 :原文 这 里 为 btr， 可 能 为 笔 误 ， 修 
EA bts) 。 该 指令 选 出 第 一 操作 数 所 指定 的 位 ， 存 储 它 的 值 到 ce 标志 寄存 器 ， 并 且 清 除 
第 二 操作 数 指定 的 位 数组 中 的 对 应 位 。 


__clear_bit 的 原子 性 变 体 为 clear_bit 


static _ always_inline void 
clear_bit(long nr, volatile unsigned long *addr) 


{ 
if (IS_IMMEDIATE(nr)) { 
asm volatile(LOCK_PREFIX "andb %1,%0" 
: CONST_MASK_ADDR(nr, addr) 
: "ig" ((u8)~CONST_MASK(nr))); 
} else { 
asm volatile(LOCK_PREFIX "btr %1,%0" 
: BITOP_ADDR(addr ) 
B Miele (ley ie 
} 
} 


ae ee set_bit 非常 相似 ， 只 有 两 处 不 同 。 第 一 处 差异 为 ”clear_bit 
使 用 btr SSR 青 位 ， set_bit 使 用 bts SR BME © 第 二 处 差 HA clear_bit 使 用 
否定 的 位 掩 码 和 ” 按 位 与 erat 而 set_bit 使 用 按 位 或 指令 


到 此 为 止 ， 我 们 可 以 在 任意 位 数组 置 位 和 清 位 了 ， 我 们 将 看 看 位 掩 码 上 的 其 他 操作 。 


在 Linux 内 核 中 对 位 数组 最 广泛 使 用 的 操作 是 设置 和 清除 位 ， 但 是 除了 这 两 个 操作 外 ， 位 数 
组 上 其 他 操作 也 是 非常 有 用 的 。Linux 内 核 里 另 一 种 广泛 使 用 的 操作 是 知晓 位 数组 中 一 个 给 定 
的 位 是 否 被 置 位 。 我 们 能 够 通过 test_bit 宏 的 帮助 实现 这 一 功能 。 这 个 宏 定 义 于 
arch/x86/include/asm/bitops.h 头 文 件 ， 并 根据 位 号 分 别 展 开 为 constant_test_bit 或 


variable_test_bit 调用 。 


#define test_bit(nr, addr) \ 
(__builtin_constant_p((nr) ) \ 
? constant_test_bit((nr), (addr)) \ 
: variable_test_bit((nr), (addr))) 


因此 ， 如 果 nr 是 是 编译 期 已 知 常 量 ” test_bit l constant_test_bit py A A) E A 2 
而 其 他 情况 则 为 variable_test_bit 。 现 在 让 我 们 看 看 这 些 函 数 的 实现 ， 让 我 们 从 
variable_test_bit 开始 看 起 : 


static inline int variable_test_bit(long nr, volatile const unsigned long *addr) 


{ 
int oldbit; 


asm volatile("bt %2,%1\n\t" 
"Sbb %0,%0" 
: "=r" (oldbit) 
: "m" (*(unsigned long *)addr), "Ir" (nr)); 


return oldbit; 


variable test bit 函数 使 用 了 与 set bit 及 其 他 函数 使 用 的 相似 的 参数 集合 。 我 们 也 可 以 
看 到 执行 bt 和 sbb 指令 的 内 联 汇 编 代码 。 pt (或 称 bit test ) 指令 从 第 二 操作 数 指定 的 
位 数组 选 出 第 一 操作 数 指定 的 一 个 指定 位 ， 并 且 将 该 位 的 值 存 进 标志 寄存 器 的 CF 位。 第 二 个 
HS sb 从 第 二 操作 数 中 减 去 第 一 操作 数 ， 再 减 去 ce 的 值 。 因 此 ， 这 里 将 一 个 从 给 定位 
数组 中 的 给 定位 号 的 值 写 进 标志 寄存 器 的 ce 位 ， 并 且 执行 sbb 指令 计算 : ooo00000 - 

cr ， 并 将 结果 写 进 oldbit 变量 。 


constant_test_bit HART Fe RAE set_bit 所 看 到 的 一 样 的 事 : 


static _ always_inline int constant_test_bit(long nr, const volatile unsigned long *ad 
dr) 


{ 
return ((1UL << (nr & (BITS_PER_LONG-1))) & 


(addr[nr >> _BITOPS_LONG_SHIFT])) != 0; 


它 生成 了 一 个 位 号 对 应 位 为 高 位 1 ， 而 其 他 位 为 9 的 字 节 (正如 我 们 在 coNST_MASK 所 看 
到 的 ) ， 并 将 按 位 与 应 用 于 包含 给 定位 号 的 字 节 。 


下 一 个 被 广泛 使 用 的 位 数组 相关 操作 是 改变 一 个 位 数组 中 的 位 。 为 此 ，Linux 内 核 提 供 了 两 个 
4 BA Be: 


e __change_bit ; 


èe change_bit . 


你 可 能 已 经 猜测 到 ’ 就 拿 set bit 和 set bit 例子 说 ， 这 两 个 变 体 分别 是 原子 和 非 原子 
MA. KA’ RMA change bit 函数 的 实现 : 


static inline void __change_bit(long nr, volatile unsigned long *addr) 


{ 
asm volatile("btc %1,%0" : ADDR : "Ir" (nr)); 


} 


相当 简单 ， 不 是 吗 ? change bit 的 实现 和 _ set_bit 一 样 ， 只 是 我 们 使 用 btc 替换 bts 
指令 而 已 。 该 指令 从 一 个 给 定位 数组 中 选 出 一 个 给 定位 ， 将 该 为 位 的 值 存 进 ce 并 使 用 求 反 
操作 改变 它 的 值 ， 因 此 值 为 1 的 位 将 变 为 9 ， 反 之 亦 然 : 


>>> int(not 1) 
0 
>>> int(not 0) 
1 


_change_bit 的 原子 版 本 为 change_bit WA: 


static inline void change_bit(long nr, volatile unsigned long *addr) 
{ 
if (IS_IMMEDIATE(nr)) { 
asm volatile(LOCK_PREFIX "xorb %1,%0" 
: CONST_MASK_ADDR(nr, addr) 
: "ig" ((u8)CONST_MASK(nr))); 
} else { 
asm volatile(LOCK_PREFIX "btc %1,%0" 
: BITOP_ADDR(addr) 
Maree (Cntr) Ve 


它 和 set_bit 函数 很 相似 ， 但 也 存在 两 点 不 同 。 第 一 处 差异 为 xor 操作 而 不 是 or 。 第 二 
处 差异 为 bte ( LCTT 译 注 :原文 为 bts ， 为 作者 笔 误 ) MAE bts ° 


目前 ， 我 们 了 解 了 最 重要 的 体系 特定 的 位 数组 操作 ， 是 时 候 看 看 一 般 的 位 图 APl 了 。 


通用 位 操作 


除了 arch/x86/include/asm/bitops.h 中 体系 特定 的 API 外 ，Linux 内 核 提 供 了 操作 位 数组 的 通 
用 API。 正 如 我 们 本 部 分 开头 所 了 解 的 一 样 ， 我 们 可 以 在 include/linux/bitmap.h 头 文 件 和 
lib/bitmap.c 源 文 件 中 找到 它 。 但 在 查看 这 些 源 文 件 之 前 ， 我 们 先 看 看 include/linux/bitops.h 
头 文件 ， 其 提供 了 一 系列 有 用 的 宏 ， 让 我 们 看 看 它们 当中 一 部 分 。 


首先 我 们 看 看 以 下 4 个 宏 : 


@ for each set bit 


@ for each _ set bit from 





@ for each clear_ bit 


@ for each clear _ bit from 





所 有 这 些 宏 都 提供 了 遍历 位 数组 中 某 些 位 集合 的 迭代 器 。 第 一 个 宏和 迭代 那些 被 置 位 的 位 。 第 
二 个 宏 也 是 一 样 ， 但 它 是 从 某 一 个 确定 的 位 开始 。 最 后 两 个 宏 做 的 一 样 ， 但 是 迭代 那些 被 清 
位 的 位 。 让 我 们 看 看 for each_set bit & : 


#define for_each_set_bit(bit, addr, size) \ 


for ((bit) = find_first_bit((addr), (size)); \ 
(bit) < (size); \ 
(bit) = find_next_bit((addr), (size), (bit) + 1)) 


正如 我 们 所 看 到 的 ， 它 使 用 了 三 个 参数 ， 并 展开 为 一 个 循环 ， 该 循环 从 作为 ”find_first_bit 
函数 返回 结果 的 第 一 个 置 位 开始 ， 到 小 于 给 定 大 小 的 最 后 一 个 置 位 为 止 。 


除了 这 四 个 宏 ，arch/x86/include/asm/bitops.h 也 提供 了 64-bit 或 32-bit 变量 循环 的 


Jo ee 


API 等 等 。 
下 一 个 头 文件 提供 了 操作 位 数组 的 APl。 例 如 ， 它 提供 了 以 下 两 个 函数 : 


e bitmap_zero ; 


e bitmap_fill . 
它们 分 别 可 以 清除 一 个 位 数组 和 用 1 填充 位 数组 。 让 我 们 看 看 bitmap zero 函数 的 实现 : 


static inline void bitmap_zero(unsigned long *dst, unsigned int nbits) 


{ 
if (small const_nbits(nbits)) 
*dst = OUL; 
else { 
unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long); 
memset(dst, 0, len); 
} 
} 


首先 我 们 可 以 看 到 对 nbits 的 检查 。 


= 


Ba? 


small_const_nbits 是 一 个 定义 在 同一 个 头 文件 的 


#define small_const_nbits(nbits) \ 


(__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG) 


正如 我 们 可 以 看 到 的 ， 它 检查 nbits 是 否 为 编译 期 已 知 常量 ， 并 且 其 值 不 超过 
BITS_PER_LONG 或 64 。 如 果 位 数目 没有 超过 一 个 long es 我 们 可 以 仅仅 设置 为 


0。 在 其 他 情况 ， 我 们 需要 计算 有 多 少 个 需要 填充 位 数组 的 long 变量 并 且 使 用 memset 进行 
填充 。 


bitmap_fill ‘4x49 EI Fe biramp zero 函数 很 相似 ， 除 了 我 们 需要 在 给 定 的 位 数组 中 填写 
oxff 或 0b11111111 


static inline void bitmap_fill(unsigned long *dst, unsigned int nbits) 
{ 
unsigned int nlongs = BITS_TO_LONGS(nbits); 
if (!small_const_nbits(nbits)) { 
unsigned int len = (nlongs - 1) * sizeof(unsigned long); 
memset(dst, Oxff, len); 
} 


dst[nlongs - 1] = BITMAP_LAST_WORD_MASK(nbits); 


除了 bitmap_fill 和 bitmap_zero ° include/linux/bitmap.h 头 文件 也 提供 了 和 bitmap_zero 
很 相似 的 bitmap_copy ， 只 是 仅仅 使 用 memcpy 而 不 是 memset 这 点 差异 而 已 。 它 也 提供 了 
位 数组 的 按 位 操作 ， 像 bitmap_and ，bitmap_or , bitamp_xor 等 等 。 我 们 不 会 探讨 这 些 函 数 
的 实现 了 ， 因 为 如 果 你 理解 了 本 部 分 的 所 有 内 容 ， 这 些 函 数 的 实现 是 很 容易 理解 的 。 无 论 如 
何 ， 如 果 你 对 这 些 函 数 是 如 何 实现 的 感 兴趣 ， 你 可 以 打开 并 研究 include/linux/bitmap.h 头 文 
件 。 


本 部 分 到 此 为 止 。 


注 : 本 文 由 LCTT 原创 翻译 ，Linux 中 国 荣誉 推出 
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这 一 章 描述 各 种 理论 性 概念 和 那些 不 直接 涉及 实践 ， 但 是 知道 了 会 很 有 用 的 概念 。 


e Elf64 格式 
e 内 联 汇编 


分 页 


简介 


在 Linux 内 核 启 动 过 程 中 的 第 五 部 分 ， 我 们 学 到 了 内 核 在 启动 的 最 早 阶 段 都 做 了 哪些 工作 。 
接 下 来 ， 在 我 们 明白 内 核 如 何 运 行 第 一 个 init 进程 之 前 ， 内 核 初始 化 其 他 部 分 ， 比 如 加 载 
initrd ， 和 初始 化 lockdep ， 以 及 许多 许多 其 他 的 工作 。 


是 的 ， 那 将 有 很 多 不 同 的 事 ， 但 是 还 有 更 多 更 多 更 多 关于 内 存 的 工作 。 


在 我 看 来 ， 一 般 而 言 ， 内 存 管 理 是 Linux 内 核 和 系统 编程 最 复杂 的 部 分 之 一 。 这 就 是 为 什么 
在 我 们 学 习 内 核 初 始 化 过 程 之 前 ， 需 要 了 解 分 页 。 


分 页 是 将 线性 地 址 转换 为 物理 地 址 的 机 制 。 如 果 我 们 已 经 读 过 了 这 本 书 之 前 的 部 分 ， 你 可 能 
记得 我 们 在 实 模式 下 有 分 段 机 制 ， ee 加 上 偏 移 算 出 来 的 。 
我 们 也 看 了 保护 模式 下 的 分 段 机 制 ， 其 中 我 们 使 用 描述 符 表 得 到 描述 符 ， 进 而 得 到 基地 址 ， 
A Eto L/S O « HTAMA 64 EBA > ANAS LIA - 


正如 Intel 手册 中 说 的 : 


分 页 机 制 提 供 一 种 机 制 ， 为 了 实现 常见 的 按 需 分 页 ， 比 如 虚拟 内 存 系统 就 是 将 一 个 程序 
执行 环境 中 的 段 按照 需 a 


所 以 ... 在 这 个 帖子 中 我 将 尝试 解释 分 页 背后 的 理论 。 当 然 它 将 与 64 位 版 本 的 Linux 内 核 关 系 
密切 ， 但 是 我 们 将 不 会 深入 大多 细节 (至少 在 这 个 帖子 里 面 ) © 


开 尼 分 页 


有 三 种 分 页 模式 : 


我 们 这 里 将 只 解释 最 后 一 种 模式 。 为 了 开启 IA-32e 分 页 模式 ， 我 们 需要 做 如 下 事情 


e 设置 CRO.PG 位 ; 
e 设置 CR4.PAE 位 ; 


e 设置 IA32 EFER.LME 位 。 


我 们 已 经 在 arch/x86/boot/compressed/head 64.S 中 看 见 了 这 些 位 被 设置 了 : 


movl $(X86_CRO_PG | X86_CRO_PE), %eax 
movl %eax, %CrO 


and 


movl $MSR_EFER, %ecx 
rdmsr 
btsl $ _EFER_LME, %eax 
wrmsr 


分 页 数据 结构 


分 页 将 线性 地 址 分 为 固定 尺寸 的 页 。 页 会 被 映射 进入 物理 地 址 空间 或 外 部 存储 设备 。 这 个 固 

ZATE x86_64 内 核 中 是 4696 字 节 。 为 了 将 ee s ga a ， 需 要 使 用 到 一 些 
寺 构 。 每 个 结构 都 是 4696 字 节 并 包含 512 项 (这 只 为 PAE 和 IA32_EFER.LME 
模式 ) 。 分 页 结构 是 层次 级 的 ，Linux ARE x86_64 框架 中 使 用 4 层 的 分 层 机 制 。CPU 使 用 
一 部 分 线性 地 址 去 确定 另 一 个 分 页 结构 中 的 项 ， 这 个 分 页 结构 可 能 在 最 低层 ， 物 理 内 存 区 域 

(RE) ， 在 这 个 区 域 的 物理 地 址 【页 偏 移 ) 。 最 高 层 的 分 页 结构 的 地 址 存储 在 cr3 寄存 器 

中 。 我 们 已 经 从 arch/x86/boot/compressed/head 64.S 这 个 文件 中 已 经 看 到 了 。 


leal pgtable(%ebx), %eax 
movl %eax, %cr3 


我 们 构建 页 表 结 构 并 且 将 这 个 最 高 层 结构 的 地 址 存放 在 cr3 寄存 器 中 。 这 里 cr3 用 于 存储 
最 高 层 结构 的 地 址 ， 在 Linux 内 核 中 被 称 为 PML4 或 Page Global Directory ° cr3 是 一 个 
64 位 的 寄存 器 ， 并 且 有 着 如 下 的 结构 : 


63 52 51 32 
| | | 
| Reserved MBZ | Address of the top level structure | 
| | | 
31 12 11 5 4 3 2 0 
| | SS se | | 
| Address of the top level structure | Reserved J} c | Ww | Reserved | 
| | o | 


这 些 字 段 有 着 如 下 的 意义 : 


。 第 0 到 第 2 位 -忽略 ; 

。 第 12 位 到 第 51 位 - 存储 最 高 层 分 页 结构 的 地 址 ; 

e 第 3 位 到 第 4 位 -PWT 或 Page-Level Writethrough 和 PCD 或 Page-level Cache 
Disable 显示 。 这 些 位 控制 页 或 者 页 表 被 硬件 缓存 处 理 的 方式 ; 

o 保留 位 - 保留 ， 但 必须 为 0 ; 

。 第 52 到 第 63 位 -保留 ， 但 必须 为 0 ; 


线性 地 址 转换 过 程 如 下 所 示 : 


oe a had 

© 64 位 线性 地 址 分 为 很 多 部 分 。 只 有 低 48 位 是 有 意义 的 ， 它 意味 着 2048 或 256TB 的 线 
ne i ne 

© crs 寄存 器 存储 这 个 最 高 层 分 页 数据 结构 的 地 址 ; 

0 给 定 的 线性 地 址 中 的 第 39 位 到 第 47 位 存储 一 个 第 4 级 分 页 结构 的 索引 ， 第 30 位 到 第 
38 位 存储 一 个 第 3 级 分 页 结构 的 索引 ， 第 29 位 到 第 21 位 存储 一 个 第 2 级 分 页 结构 的 索 
引 ， 第 12 位 到 第 20 位 存储 一 个 第 1 级 分 页 结构 的 索引 ， 第 0 位 到 第 11 位 提供 物理 页 
的 字 节 偏 移 ; 

按照 图 示 ， 我 们 可 以 这 样 想 象 它 : 

Virtual Address 


63 48 47 3938 30 29 2120 12 11 0 
Page-Map 
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*This is an architectural limit. A given processor 
51 12 implementation may support fewer bits. 
| Page-Map Level-4 
CR3 


cle a A dd 态 访 问 。 这 个 访问 是 被 cpL (current 
Privilege Level) 所 决定 。 如 果 cpL <3 ， 那 么 ren ， 否则 ， 它 就 是 用 户 态 访 问 
ee erra sy 


| | | M |I] | P | P lvIwl | 
| Address of the paging structure on lower level | AVL | B |GJA| C I WwW | | | P| 
| | |Z IN] | D | T [SIRI | 


其 中 
© 第 63 位 -N/X 位 (不 可 执行 位 ) 显示 被 这 个 页 表 项 映射 的 所 有 物理 页 执行 代码 的 能 力 ; 
© 第 52 位 到 第 62 位 -被 CPU 和 忽略， 被 系统 软件 使 用 ; 


。 第 12 位 到 第 51 位 - 存储 低级 分 页 结构 的 物理 地 址 ; 

。 第 9 位 到 第 11 位 -被 CPU 忽略 ; 

e MBZ- 必须 为 0 ; 

。 忽略 位 ; 

e 人 A- 访问 位 上 暗示 物理 页 或 者 页 结构 被 访问 ; 

。 PWT 和 PCD 用 于 缓存 ; 

© U/S- 用 户 /管理 位 控制 对 被 这 个 页 表 项 映射 的 所 有 物理 页 用 户 访问 ; 
© RIW - 读 写 位 控制 着 被 这 个 页 表 项 映射 的 所 有 物理 页 的 读 写 权限 

o 已 -存在 位 。 当 前 位 表示 页 表 或 物理 页 是 否 被 加 载 进 内 存 ; 


好 的 ， 我 们 知道 了 分 页 结构 和 它们 的 表 项 。 现 在 我 们 来 看 一 下 Linux 内 核 中 的 4 级 分 页 机 制 
的 一 些 细节 。 


Linux 内 核 中 的 分 页 结构 


就 如 我 们 已 经 看 到 的 那样 ， x86_64 Linux 内 核 使 用 4 级 页 表 。 它 们 的 名 字 是 : 


e 全 局 页 目录 
e 上 层 页 目录 
中 间 页 目录 
RRA 


在 你 已 经 编译 和 安装 Linux 内 核 之 后 ， 你 可 以 看 到 保存 了 内 核 函 数 的 虚拟 地 址 的 文件 
System.map 。 例 如 : 


$ grep "start_kernel" System.map 
ffffffff81efe497 T x86_64_start_kernel 
ffffffff81efeaa2 T start_kernel 


这 里 我 们 可 以 看 见 exffffffff81efe497 ° MIFRMMRESANARRRASHH o AAE 
fT > start_kernel 和 xg6_64_start_kernel 将 会 被 执行 。 在 x86_64 ， 地 址 空间 的 大 小 
是 2^64 ， 但 是 它 太 大 了 ， 这 就 是 为 什么 我 们 使 用 一 个 较 小 的 地 址 空间 ， 只 是 48 位 的 宽度 。 
所 以 一 个 情况 出 现 ， 虽 然 物理 地 址 空间 限制 到 48 位 ， 但 是 寻 址 仍然 使 用 64 位 指针 。 这 个 问 
题 是 如 何 解决 的 ?看 下 面 的 这 个 表 。 


6xffffffffffffffff +----------- 
| | 
| | Kernelspace 
| | 
Oxf ffF800000000000 +----------- 十 
| | 
| | 
| hole | 
| | 
| | 
OxXOOOO7FFFFFFFFFFF +----------- is 
| | 
| | Userspace 
| | 
0x0000000000000000 +----------- a 


这 个 解决 方案 是 sign extension 。 这 里 我 们 可 以 看 到 一 个 虚拟 地 址 的 低 48 位 可 以 被 用 于 寻 
址 。 第 48 位 到 第 63 位 全 是 0 或 1。 注意 这 个 虚拟 地 址 空间 被 分 为 两 部 分 


e 内 核 空间 
e 用 户 空间 


用 户 空间 占用 虚拟 地 址 空间 的 低 部 分 ， 从 oxooooooooooooooo 到 6xgg697fffffffffff > mA 
核 空间 占据 从 gxffff8666060000 到 Qxffffffffffffffff 的 高 部 分 。 注 意 ， 第 48 位 到 第 63 
位 是 对 于 用 户 空间 是 0 ， 对 于 内 核 空 间 是 1。 内核 空间 和 用 户 空间 中 的 所 有 地 址 是 标准 地 

址 ， 本 。 这 两 块 内 存 区 域 ( 内核 空 间 和 用 户 空间 ) 合 起 来 
是 48 位 宽度 。 我 们 可 以 在 Documentation/x86/x86_64/mm.txt 找到 4 级 页 表 下 的 虚拟 内 存 映 
射 : 


0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm 
hole caused by [48:63] sign extension 
ffff300000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor 
ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory 
ffffc80000000000 - ffffc8ffffffffff (=40 bits) hole 
ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space 
ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole 
ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB) 

. unused hole ... 
ffffecooo00000000 - fffffc0000000000 (=44 bits) kasan shadow memory (16TB) 

. unused hole ... 
ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks 

. unused hole ... 
ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0 
ffffffffa0000000 - ffffffffffo5fffff (=1525 MB) module mapping space 
ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls 
ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole 


这 里 我 们 可 以 看 到 用 户 空 间 ， 内 核 空 间 和 非 标 准 空间 的 内 存 映射 。 用 户 空间 的 内 存 映射 很 简 
单 。 让 我 们 来 更 近 地 查 看 内 核 空间 。 我 们 可 以 看 到 它 始 于 为 管理 程序 (hypervisor) 保留 的 防御 
空洞 (guard hole) 。 我 们 可 以 在 arch/x86/include/asm/page_64_types.h 这 个 文件 中 看 到 防御 
空洞 的 概念 ! 


#define __PAGE_OFFSET _AC(Qxffff880000000000, UL) 


以 前 防御 空洞 和 ”PAGE_OFFSET 是 从 Qxffff86606006600660 到 goxffff89ffffffffff ， 用 来 防 
止 对 非 标准 区 域 的 访问 ， 但 是 后 来 为 了 管理 程序 扩展 了 3 位 。 


紧 接着 是 内 核 空间 中 最 低 的 可 用 空间 - frrrssoooooooooo 。 这 个 虚拟 地 址 空间 是 为 了 所 有 的 
物理 内 存 的 直接 映射 。 在 这 块 空间 之 后 ， 还 是 防御 空洞 。 它 位 于 所 有 物理 内 存 的 直接 映射 地 
址 和 被 vmalloc 分 配 的 地 址 之 间 。 在 第 一 个 1TB 的 虚拟 内 存 映射 和 无 用 的 空洞 之 后 ， 我 们 可 
以 看 到 ksan 影子 内 存 (shadow memory)。 它 是 通过 commit 提交 到 内 核 中 ， 并 且 保 持 内 核 
空间 无 害 。 在 紧 接着 的 无 用 空洞 之 后 ， 我 们 可 以 看 到 esp ER (我们 会 在 本 书 其 他 部 分 讨 
WE) 。 内 核 代码 段 的 开始 从 物理 地 址 - @ 映射 。 我 们 可 以 在 相同 的 文件 中 找到 将 这 个 地 址 


定义 为 PAGE OFFSET ° 


#define START_KERNEL_map _AC(Oxffffffff80000000，UL) 





内 核 的 text 段 开 始 于 coNFIG_PHYSICAL_START 偏 移 。 我 们 已 经 在 ELF64 相关 帖子 中 


readelf -s vmlinux | grep ffffffff81000000 


1: ffffffff81000000 9 SECTION LOCAL DEFAULT 1 
65099: ffffffff81000000 9 NOTYPE GLOBAL DEFAULT 1 _text 
90766: ffffffff81000000 9 NOTYPE GLOBAL DEFAULT 1 startup_64 


这 里 我 将 CONFIG_PHYSICAL_START 设置 为 ox1000000 来 检查 vmlinux 。 所 以 我 们 有 内 核 代 
码 段 的 起 始点 - 9xffffffff899009999 和 偏 移 - oxioooooo ， 计 算出 来 的 虚拟 地 址 将 会 是 


Oxffffffff80000000 + 1000000 = Oxffffffff81000000 ° 

在 内 核 代 码 段 之 后 有 一 个 为 内 核 模 块 vsyscalls 准备 的 虚拟 内 存 区 域 和 2M 无 用 的 空洞 。 
我 们 已 经 看 见 内 核 庶 拟 内 存 映射 是 如 何 布局 的 以 及 虚拟 地 址 是 如 何 转 换 位 物理 地 址 。 让 我 们 
以 下 面 的 地 址 为 例 : 


Oxffffffff81000000 


在 二 进 制 内 它 将 是 : 


1111111111111111 111111111 111111110 000001000 000000000 000000000000 
63:48 47:39 38:30 29:21 20:12 11:0 


这 个 虚拟 地 址 将 被 分 为 如 下 描述 的 几 部 分 : 


e 48-63 -不 使 用 的 位 ; 

e 37-49 - 给 定 线性 地 址 的 这 些 位 描述 一 个 4 级 分 页 结构 的 索引 s 
e 30-38 eprvrwerverty 7 ; 

© 21-29 - | 2 级 分 页 结构 的 索引 ; 

e 12-20 - 这 些 位 存储 一 个 1 级 分 页 结构 的 索引 ; 

e 96-11 -这些 位 提供 物理 页 的 偏 移 ; 


就 这 样 了 。 现 在 你 知道 了 一 些 关 于 分 页 理论 ， 而 且 我 们 可 以 在 内 核 源码 上 更 近 一 步 ， 查 看 那 
些 最 先 的 初始 化 步骤 。 


总 结 


~ 


这 简短 的 关于 分 页 理论 的 部 分 至 此 已 经 结束 了 。 当 然 ， 这 个 帖子 不 可 能 包含 分 页 的 所 有 细 
节 ， 但 是 我 们 很 快 会 看 到 在 实践 中 Linux 内 核 如 何 构建 分 页 结构 以 及 使 用 它们 工作 。 


pEi 
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ELF 文 件 格式 


ELF (Executable and Linkable Format) 是 一 种 为 可 执行 文件 ， 目 标 文件 ， 共 享 链接 库 和 内 核 
$k fă (core dumps) 准 备 的 标准 文件 格式 。 Linux 和 很 多 类 Unix 操 作 系 统 都 使 用 这 个 格式 。 让 我 
们 来 看 一 下 64 位 ELF 文 件 格式 的 结构 以 及 内 核 源码 中 有 关于 它 的 一 些 定义 。 


一 个 ELF 文 件 由 以 下 三 部 分 组 成 : 


e ELF 头 (ELF header) - 描述 文件 的 主要 特性 : 类 型 ，CPU 架 构 ， 入 口 地址 ， 现 有 部 分 的 大 


小 和 偏 移 等 等 ; 


e 程序 头 表 (Program header table) - 列举 了 所 有 有 效 的 段 (segments) 和 他 们 的 属性 。 程序 
头 表 需 要 加 载 器 将 文件 中 的 节 加 载 到 虚拟 内 存 段 中 ; 


。 节 头 表 (Section header table) - 包含 对 节 (sections) 的 描述 。 
现在 让 我 们 对 这 些 部 分 有 一 些 更 深 的 了 解 。 
ELF (ELF header) 


ELF 头 (ELF header) 位 于 文件 的 开始 位 置 。 它 的 主要 目的 是 定位 文件 的 其 他 部 分 。 文 件 头 主 
要 包含 以 下 字段 : 


。 ELF 文 件 鉴定 -一 个 字 节 数组 用 来 确认 文件 是 否 是 一 个 ELF 文 件 ， 并 且 提 供 普 通 文件 特征 
的 信息 ; 

© 文件 类 型 - 确定 文件 类 型 。 这 个 字段 描述 文件 是 一 个 重 定位 文件 ， 或 可 执行 文件 ,或 .… ; 

e 目标 结构 ; 

© ELF 文 件 格 式 的 版 本 ; 

o 程序 入 口 地 址 ; 

© 程序 头 表 的 文件 偏 移 ; 

© 节 头 表 的 文件 偏 移 ; 

e ELF 头 (ELF header) 的 大 小 ; 

© 程序 头 表 的 表 项 大 小 ; 

o 其 他 字段 ... 


你 可 以 在 内 核 源 码 种 找到 表示 ELF64 header 的 结构 体 elf64 hdr : 


typedef struct elf64_hdr { 
unsigned char e_ident[EI_NIDENT]; 
E1f64_Half e_type; 
E1f64_Half e_machine; 
Elf64 _ Word e_version; 
E1f64_Addr e_entry; 
E1f64_Off e_phoff; 
E1f64_Off e_shoff; 
E1f64_Word e_flags; 
E1f64_Half e_ehsize; 
E1f64_Half e_phentsize; 
E1f64_Half e_phnum; 
E1f64_Half e_shentsize; 
E1f64_Half e_shnum; 
E1f64_Half e_shstrndx; 

} Elf64_Ehdr; 


这 个 结构 体 定义 在 elf.h 
节 (sections) 


所 有 的 数据 都 存储 在 ELF 文 件 的 节 (sections) 中 。 我 们 通过 节 头 表 中 的 索引 (index) 来 确认 节 
(sections)。 节 头 表 表 项 包含 以 下 字段 : 


e 节 的 名 字 ; 

e 节 的 类 型 ; 

e 节 的 属性 ; 

e 内 存 地 址 ; 

o 文件 中 的 偏 移 ; 

e 节 的 大 小 ; 

o 到 其 他 节 的 链接 ; 

© 各 种 各 样 的 信息 ; 

e 地 址 对 齐 ; 

© 这 个 表 项 的 大 小 ， 如 果 有 的 话 ; 


而 有 全， 在 linux 内 核 中 结构 体 elf64_shdr 如 下 所 示 : 


typedef struct elf64_shdr { 
Elf64 Word sh_name; 
E1f64_Word sh_type; 
E1f64_Xword sh_flags; 
E1f64_Addr sh_addr; 
E1f64_Off sh_offset; 
E1f64_Xword sh_size; 
Elf64 Word sh_link; 
Elf64 Word sh_info; 
E1f64_Xword sh_addralign; 
E1f64_Xword sh_entsize; 

} Elf64_Shdr; 


elf.h 
42% k # (Program header table) 


在 可 执行 文件 或 者 共享 链接 库 中 所 有 的 节 (sections) 都 被 分 为 多 个 段 (segments)。 程序 头 是 一 
个 结构 的 数组 ， 每 一 个 结构 都 表示 一 个 段 (segments)。 它 的 结构 就 像 这 样 : 


typedef struct elf64_phdr { 
E1f64_Word p_type; 
E1f64_Word p_flags; 
E1f64_Off p_offset; 
E1f64_Addr p_vaddr; 
E1f64_Addr p_paddr; 
E1f64_Xword p_filesz; 
E1f64_Xword p_memsz; 
E1f64_Xword p_align; 

} E1f64_Phdr; 


在 内 核 源码 中 。 
elf64_phdr 定义 在 相同 的 elf.h 文件 中 . 


EFL 文 件 也 包含 其 他 的 字段 或 结构 。 你 可 以 在 Documentation 中 查看 。 现在 我 们 来 查看 一 下 
vmlinux 这 个 ELF 文 件 。 


vmlinux 


vmlinux 也 是 一 个 可 重 定 位 的 ELF 文 件 。 我 们 可 以 使 用 readelf 工具 来 查看 它 。 首 先 ， 让 
我 们 看 一 下 它 的 头 部 : 


$ readelf -h vmlinux 


ELF Header: 
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
Class: ELF64 
Data: 2's complement, little endian 
Version: 1 (current) 
OS/ABI: UNIX - System V 
ABI Version: 0 
Type: EXEC (Executable file) 
Machine: Advanced Micro Devices X86-64 
Version: 0x1 
Entry point address: 0x1000000 
Start of program headers: 64 (bytes into file) 
Start of section headers: 381608416 (bytes into file) 
Flags: 0x0 
Size of this header: 64 (bytes) 
Size of program headers: 56 (bytes) 
Number of program headers: 5 
Size of section headers: 64 (bytes) 
Number of section headers: 73 


Section header string table index: 70 


我 们 可 以 看 出 vmlinux 是 一 个 64 位 可 执行 文件 。 我 们 可 以 从 
Documentation/x86/x86_64/mm.txt 读 到 相关 信息 : 


ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0 


之 后 我 们 可 以 在 vmlinux ELF 文 件 中 查看 这 个 地 址 : 


$ readelf -s vmlinux | grep ffffffff81000000 


1: ffffffff81000000 9 SECTION LOCAL DEFAULT 1 
65099: ffffffff81000000 9 NOTYPE GLOBAL DEFAULT 1 _text 
90766: ffffffff81000000 9 NOTYPE GLOBAL DEFAULT 1 startup_64 


值得 注意 的 是 ， startup 64 例 程 的 地 址 不 是 ffffffff80000000 , 而 是 ffffffff81000000 ° 
现在 我 们 来 解释 一 下 。 


我 们 可 以 在 arch/x86/kernel/vmlinux.lds.S 看 见 如 下 的 定义 : 


» = START KERNEL ， 


/* Text and read-only data */ 
.text : AT(ADDR(.text) - LOAD_OFFSET) { 
-text = .; 


其 中 ， START_KERNEL 定义 如 下 : 


#define _ START_KERNEL (__START_KERNEL_map + PHYSICAL_START ) 








从 这 个 文档 中 看 出 ， START_KERNEL map 的 值 是 ffffffff80000000 以 及 _ PHYSICAL_START 


的 值 是 gx1660060 ° 这 就 是 startup_ 64 的 地 址 是 ffffffff81000000 的 原因 了 。 


是 
最 后 我 们 通过 以 下 命令 来 得 到 程序 头 表 的 内 容 : 


readelf -1 vmlinux 


Elf file type is EXEC (Executable file) 
Entry point 0x1000000 
There are 5 program headers, starting at offset 64 


Program Headers: 


Type offset VirtAddr PhysAddr 
FileSiz MemSiz Flags Align 

LOAD 0x0000000000200000 OxfffffFFF81000000 0x0000000001000000 
0x0000000000cfd000 0x0000000000cfd000 RE 200000 

LOAD 0x0000000001000000 90xffffffff81e00000 0x0000000001e00000 
0x0000000000100000 0x0000000000100000 RW 200000 

LOAD 0x0000000001200000 0x0000000000000000 0x0000000001f00000 
0x0000000000014d98 0x0000000000014d98 RW 200000 

LOAD 0x0000000001315000 Qxffffffff81f15000 0x0000000001F15000 
0x000000000011d000 0x0000000000279000 RWE 200000 

NOTE 0x0000000000b17284 0xffffffff81917284 0x0000000001917284 
0x0000000000000024 0x0000000000000024 4 


Section to Segment mapping: 
Segment Sections... 


00 .text .notes __ex_table .rodata __bug_table .pci_fixup .builtin_fw 
.tracedata _ksymtab __ksymtab_gpl __kcrctab __kcrctab_gpl 
__ksymtab_strings _ param __modver 

01 .data .vvar 

02 .data. .percpu 

03 .init.text .init.data .x86_cpu_dev.init .altinstructions 


.altinstr_replacement .iommu_table .apicdrivers .exit.text 
.smp_locks .data_nosave .bss .brk 


这 里 我 们 可 以 看 出 五 个 包含 节 (sections) 列 表 的 段 (segments)。 
arch/x86/kernel/vmlinux.lds 中 找到 所 有 的 节 (sections) ° 


你 可 以 在 生成 的 链接 器 脚本 - 


就 这 样 吧 。 当然 ， 它 不 是 ELF(Executable and Linkable Format) 的 完整 描述 ， 但 是 如 果 你 想 
要 知道 更 多 ， 可 以 参考 这 个 文档 - 这 里 


Inline assembly 


Introduction 


While reading source code in the Linux kernel, | often see statements like this: 


asm ("andq %%rsp,%0; ":"=r" (ti) : "©" (CURRENT_MASK) ); 


Yes, this is inline assembly or in other words assembler code which is integrated in a high 
level programming language. In this case the high level programming language is C. Yes, 
the c programming language is not very high-level, but still. 


If you are familiar with the assembly programming language, you may notice that inline 
assembly is not very different from normal assembler. Moreover, the special form of inline 
assembly which is called basic form is exactly the same. For example: 


asm__("movq %rax, %rsp"); 


or: 


__asm__("hlt"); 


The same code (of course without _asm_ prefix) you might see in plain assembly code. 


Yes, this is very similar, but not so simple as it might seem at first glance. Actually, the GCC 
supports two forms of inline assembly statements: 


© basic ; 


© extended. 


The basic form consists of only two things: the _ asm keyword and the string with valid 
assembler instructions. For example it may look something like this: 


__asm__("movq $3, %rax\t\n" 
"movq %rsi, %rdi"); 


The asm keyword may be used in place of _asm , however _asm_ is portable 
whereas the asm keyword isa enu extension. In further examples | will only use the 
__asm__ variant. 


fyou know assembly programming language this looks pretty familiar. The main problem is 
in the second form of inline assembly statements - extended . This form allows us to pass 
parameters to an assembly statement, perform jumps etc. Does not sound difficult, but 
requires knowledge of special rules in addition to knowledge of the assembly language. 
Every time | see yet another piece of inline assembly code in the Linux kernel, | need to refer 
to the official documentation of ccc to remember how a particular qualifier behaves or 
what the meaning of =&r is for example. 


I've decided to write this part to consolidate my knowledge related to the inline assembly, as 
inline assembly statements are quite common in the Linux kernel and we may see them in 
linux-insides parts sometimes. | thought that it would be useful if we have a special part 
which contains information on more important aspects of the inline assembly. Of course you 
may find comprehensive information about inline assembly in the official documentation, but 
| like to put everything in one place. 


Note: This part will not provide guide for assembly programming. It is not intended to 
teach you to write programs with assembler or to know what one or another 
assembler instruction means. Just a little memo for extended asm. 


Introduction to extended inline assembly 


So, let's start. As | already mentioned above, the basic assembly statement consists of the 
asm Or __asm__ keyword and set of assembly instructions. This form is in no way different 
from "normal" assembly. The most interesting part is inline assembler with operands, or 
extended assembler. An extended assembly statement looks more complicated and 
consists of more than two parts: 


asm__ [volatile] [goto] (AssemblerTemplate 


[ : OutputOperands ] 
[ : InputOperands ] 
[ : Clobbers ] 
[ : GotoLabels We 


All parameters which are marked with squared brackets are optional. You may notice that if 
we skip the optional parameters and the modifiers volatile and goto we obtain the 
basic form. 


Let's start to consider this in order. The first optional qualifier is volatile . This specifier 
tells the compiler that an assembly statement may produce side effects . In this case we 
need to prevent compiler optimizations related to the given assembly statement. In simple 


terms the volatile specifier instructs the compiler not to modify the statement and place it 
exactly where it was in the original code. As an example let's look at the following function 
from the Linux kernel: 


static inline void native_load_gdt(const struct desc_ptr *dtr) 


{ 
asm volatile("lgdt %0"::"m" (*dtr)); 


} 


Here we see the native load gdt function which loads a base address from the Global 
Descriptor Table to the GDTR register with the ligat instruction. This assembly statement is 
marked with volatile qualifier. It is very important that the compiler does not change the 
original place of this assembly statement in the resulting code. Otherwise the GDTR register 
may contain wrong address for the Global Descriptor Table or the address may be correct, 
but the structure has not been filled yet. This can lead to an exception being generated, 
preventing the kernel from booting correctly. 


The second optional qualifier is the goto . This qualifier tells the compiler that the given 
assembly statement may perform a jump to one of the labels which are listed in the 
GotoLabels . For example: 


_asm__ goto("jmp %l[label]" : : : : label); 


Since we finished with these two qualifiers, let's look at the main part of an assembly 
statement body. As we have seen above, the main part of an assembly statement consists 
of the following four parts: 


e set of assembly instructions; 
e output parameters; 

e input parameters; 

e clobbers. 


The first represents a string which contains a set of valid assembly instructions which may 
be separated by the \t\n sequence. Names of processor registers must be prefixed with 
the %% sequence in extended form and other symbols like immediates must start with the 

$ symbol. The outputoperands and InputOperands are comma-separated lists of C 
variables which may be provided with "constraints" and the clobbers is a list of registers or 
other values which are modified by the assembler instructions from the AssemblerTemplate 
beyond those listed in the outputoperands . Before we dive into the examples we have to 
know a little bit about constraints . A constraint is a string which specifies placement of an 
operand. For example the value of an operand may be written to a processor register or 
read from memory etc. 


Consider the following simple example: 


#include <stdio.h> 


int main(void) 

{ 
unsigned long a = 5; 
unsigned long b = 10; 
unsigned long sum = 0; 


__asm__("addq %1,%2" : "=r" (sum) : "r" (a), "O" (b)); 
printf("a + b = %lu\n", sum); 
return 0; 


Let's compile and run it to be sure that it works as expected: 


$ gcc test.c -o test 
./test 
at+b= 15 


Ok, great. It works. Now let's look at this example in detail. Here we see a simple c 
program which calculates the sum of two variables placing the result into the sum variable 
and in the end we print the result. This example consists of three parts. The first is the 
assembly statement with the add instruction. It adds the value of the source operand 
together with the value of the destination operand and stores the result in the destination 
operand. In our case: 


addq %1, %2 


will be expanded to the: 


addq a, b 


Variables and expressions which are listed in the outputOperands and InputOperands may 
be matched in the AssemblerTemplate . An input/output operand is designated as %N where 
the n is the number of operand from left to right beginning from zero . The second part of 
the our assembly statement is located after the first : symbol and contains the definition of 
the output value: 


"=r" (sum) 


Notice that the sum is marked with two special symbols: =r . This is the first constraint that 
we have encountered. The actual constraint here is only r itself. The = symbol is 

modifier which denotes output value. This tells to compiler that the previous value will be 
discarded and replaced by the new data. Besides the = modifier, ccc provides support for 
following three modifiers: 


e + -an operand is read and written by an instruction; 

e & -output register shouldn't overlap an input register and should be used only for 
output; 

e % -tells the compiler that operands may be commutative. 


Now let's go back to the r qualifier. As | mentioned above, a qualifier denotes the 
placement of an operand. The r symbol means a value will be stored in one of the general 
purpose register. The last part of our assembly statement: 


"y" (a), ng" (b) 


These are input operands - variables a and b .We already know what the r qualifier 
does. Now we can have a look at the constraint for the variable b . The o or any other 
digit from 1 to 9 is called "matching constraint". With this a single operand can be used 
for multiple roles. The value of the constraint is the source operand index. In our case 0 
will match sum . If we look at assembly output of our program: 


0000000000400400 <main>: 


4004fe: 48 c7 45 f8 05 00 00 movq $0x5, -Ox8(%rbp) 


400506: 48 c7 45 fO Oa 00 00 movq $0xa, -0x10 (%rbp) 
400516: 48 8b 55 f8 mov -Ox8(%rbp), %rdx 
40051a: 48 8b 45 fO mov -0x10(%rbp), %rax 
40051e: 48 01 dO add %rdx, %rax 


First of all our values 5 and 10 will be put at the stack and then these values will be 
moved to the two general purpose registers: %rdx and %rax . 


This way the %rax register is used for storing the value of the b as well as storing the 
result of the calculation. NOTE that I've used gcc 6.3.1 version, so the resulted code of 
your compiler may differ. 


We have looked at input and output parameters of an inline assembly statement. Before we 
move on to other constraints supported by gcc , there is one remaining part of the inline 
assembly statement we have not discussed yet - clobbers . 


Clobbers 


As mentioned above, the "clobbered" part should contain a comma-separated list of 
registers whose content will be modified by the assembler code. This is useful if our 
assembly expression needs additional registers for calculation. If we add clobbered registers 
to the inline assembly statement, the compiler take this into account and the register in 
question will not simultaneously be used by the compiler. 


Consider the example from before, but we will add an additional, simple assembler 
instruction: 


asm__("movq $100, %%rdx\t\n" 
"addq %1,%2" : "=r" (sum) : "r" (a), "O" (b)); 


If we look at the assembly output: 


0000000000400400 <main>: 


4004fe: 48 c7 45 f8 05 00 00 movq $0x5, -Ox8(%rbp) 


400506: 48 c7 45 fO Oa 00 00 movq $0xa, -0x10 (%rbp) 
400516: 48 8b 55 f8 mov -Ox8(%rbp), %rdx 
40051a: 48 8b 45 fO mov -0x10(%rbp), %rax 
40051e: 48 c7 c2 64 00 00 00 mov $0x64,%rdx 
400525: 48 01 do add %r dx, %rax 


we will see that the %rdx register is overwritten with ox64 or 100 and the result will be 
110 instead of 10 . Now if we add the %rdx register to the list of clobbered registers: 


asm__("movq $100, %%rdx\t\n" 
ead Gailey ECSUmh Mie (ED, Mel (ey 8 rdx 


and look at the assembler output again: 


0000000000400400 <main>: 


4004fe: 48 c7 45 f8 05 00 00 movq $0x5, -Ox8(%rbp) 
400506: 48 c7 45 fO Oa 00 00 movq $0xa, -0x10 (%rbp) 
400516: 48 8b 4d f8 mov -0x8 (%rbp),%rcx 
40051a: 48 8b 45 fO mov -0x10 (%rbp),%rax 
40051e: 48 c7 c2 64 00 00 00 mov $0x64,%rdx 
400525: 48 01 c8 add %r CX, %raxX 


the %rcx register will be used for sum calculation, preserving the intended semantics of 
the program. Besides general purpose registers, we may pass two special specifiers. They 
are: 


e Ecc, 


© memory. 


The first- cc indicates that an assembler code modifies flags register. This is typically used 
if the assembly within contains arithmetic or logic instructions: 


asm__("incq %0" ::""(variable): "cc"); 


The second memory specifier tells the compiler that the given inline assembly statement 
executes read/write operations on memory not specified by operands in the output list. This 
prevents the compiler from keeping memory values loaded and cached in registers. Let's 
take a look at the following example: 


#include <stdio.h> 


int main(void) 


{ 
unsigned long a[3] = {10000000000, ©, 1}; 
unsigned long b = 5; 
__asm__ volatile("incq %0" :: "m" (a[0])); 
printf("a[O] - b = %lu\n", a[O] - b); 
return 0; 

} 


This example may be artificial, but it illustrates the main idea. Here we have an array of 
integers and one integer variable. The example is pretty simple, we take the first element of 
a and increment its value. After this we subtract the value of b from the first element of 
a . In the end we print the result. If we compile and run this simple example the result may 

surprise you: 


~$ gcc -03 test.c -o test 
~$ ./test 
a[0] - b = 9999999995 


The result is a[o] - b = 9999999995 here, but why? We incremented a[o] and subtracted 


b , so the result should be a[o] - b = 9999999996 here. 


If we have a look at the assembler output for this example: 


00000000004004f6 <main>: 


4004b4: 48 b8 00 e4 Ob 54 02 movabs $0x2540be400, %rax 
4004be: 48 89 04 24 mov %rax, (%rsp) 
40050e: ff 44 24 fO incq (%rsp) 

4004d8: 48 be fb e3 Ob 54 02 movabs $0x2540be3fb, %rsi 


we will see that the first element of the a contains the value ox2540be400 ( 10000000000 ). 


The last two lines of code are the actual calculations. 


We see our increment instruction with incq but then just a move of ox2540be3fb 


( 9999999995 ) tothe %rsi register. This looks strange. 


The problem is we have passed the -o3 flag to gcc , so the compiler did some constant 


folding and propagation to determine the result of a[o] - 5 at compile time and reduced it 


toa movabs with a constant ©x2540be3fb Or 9999999995 


Let's now add memory to the clobbers list: 


__asm__ volatile("incgq %0" :: "m" (a[0]) : "memory"); 


and the new result of running this is: 


~$ gcc -03 test.c -o test 
~$ ./test 
a[0] - b = 9999999996 


in runtime. 


Now the result is correct. If we look at the assembly output again: 


00000000004004f6 <main>: 


400404: 48 b8 00 e4 Ob 54 02 movabs $0x2540be400, %rax 
40040b: 00 00 00 

40040e: 48 89 04 24 mov %rax, (%rsp) 
400412: 48 c7 44 24 08 00 00 movq  $0x0,0x8(%rsp) 
400419: 00 00 

40041b: 48 c7 44 24 10 01 00 movq  $0x1,0x10(%rsp) 
400422: 00 00 

400424: 48 ff 04 24 incq (%rsp) 

400428: 48 8b 04 24 mov (%rsp),%rax 
400431: 48 8d 70 fb lea -Ox5(%rax), %rsi 


we will see one difference here which is in the last two lines: 


400428: 48 8b 04 24 mov (%rsp),%rax 
400431: 48 8d 70 fb lea -Ox5(%rax) , %rsi 


Instead of constant folding, ccc now preserves calculations in the assembly and places the 
value of aro] inthe %rax register afterwards. In the end it just subtracts the constant 
value of b fromthe %rax register and puts result to the %rsi . 


Besides the memory specifier, we also see a new constraint here - m . This constraint tells 

the compiler to use the address of a[o] , instead of its value. So, now we are finished with 
clobbers and we may continue by looking at other constraints supported by ccc besides 
r and m which we have already seen. 


Constraints 


Now that we are finished with all three parts of an inline assembly statement, let's return to 
constraints. We already saw some constraints in the previous parts, like r which 
represents a register operand, m which represents a memory operand and 0-9 which 
represent an reused, indexed operand. Besides these ccc provides support for other 
constraints. For example the i constraint represents an immediate integer operand with 
know value: 


#include <stdio.h> 


int main(void) 


{ 


int a = 0; 


asm (“movl %1, %0" : "=r"(a) : "i"(100)); 
printf("a = %d\n", a); 
KReEURN NO; 
} 
The result is: 


~$ gcc test.c -o test 
~$ ./test 
a = 100 


Or for example 1 which represents an immediate 32-bit integer. The difference between 


i and 1 isthat i is general, whereas 1 is strictly specified to 32-bit integer data. For 


example if you try to compile the following code: 


unsigned long test_asm(int nr) 


{ 
unsigned long a = 0; 
__asm__("movg %1, %0" : "=r"(a) : "I" (Oxf ffTTTTTTTTF) ); 
return a; 

} 


you will get an error: 


$ gcc -03 test.c -o test 
test.c: In function ‘test_asm’: 


test.c:7:9: warning: asm operand 1 probably doesn’t match constraints 


__asm__("movgq %1, %0" : "=r"(a) : "I"(QOxffffffffffff)); 


A 


test.c:7:9: error: impossible constraint in ‘asm’ 


when at the same time: 


unsigned long test_asm(int nr) 


{ 
unsigned long a = 0; 
__asm__("movg %1, %0 : "=r"(a) : "i" (Oxf ffFTTTTTTTF) ); 
return a; 

} 


works perfectly: 


~$ gcc -03 test.c -o test 
~$ echo $? 
0 


ccc also supports 3, K, N constraints for integer constants in the range of 0-63 bits, 
signed 8-bit integer constants and unsigned 8-bit integer constants respectively. The o 
constraint represents a memory operand with an offsetable memory address. For 
example: 


#include <stdio.h> 


int main(void) 


{ 
static unsigned long arr[3] = {0, 1, 2}; 
static unsigned long element; 
__asm__ volatile("movq 16+%1, %0" : "=r"(element) : "o"(arr)); 
printf("%lu\n", element); 
return 0; 
} 


The result, as expected: 


~$ gcc -03 test.c -0 test 
~$ ./test 
2 


All of these constraints may be combined (so long as they do not conflict). In this case the 
compiler will choose the best one for a certain situation. For example: 


#include <stdio.h> 


unsigned long a = 1; 


int main(void) 

{ 
unsigned long b; 
asm ("movg %1,%0" : "=r"(b) : "r"(a)); 
return b; 


will use a memory operand: 


0000000000400400 <main>: 
4004aa: 48 8b 05 6f Ob 20 00 mov 0x200b6f (%rip), %rax # 601020 <a> 


That's about all of the commonly used constraints in inline assembly statements. You can 
find more in the official documentation. 


Architecture specific constraints 


Before we finish, let's look at the set of special constraints. These constrains are architecture 
specific and as this book is specific to the x86_64 architecture, we will look at constraints 
related to it. First of all the set of a ... d andalso s and p constraints represent 
generic purpose registers. In this case the a constraint corresponds to %al , %ax , %eax 
or %rax register depending on instruction size. The s and p constraints are %si and 
%di registers respectively. For example let's take our previous example. We can see in its 
assembly output that value of the a variable is stored inthe %eax register. Now let's look 
at the assembly output of the same assembly, but with other constraint: 


#include <stdio.h> 


aie cl = ale 

int main(void) 

{ 
int b; 
asm ("movg %1,%0" : "=r"(b) : "d"(a)); 
return b; 

} 


Now we see that value of the a variable will be stored in the %rax register: 


0000000000400400 <main>: 
4004aa: 48 8b 05 6f Ob 20 00 mov Ox200b6f (%rip), %rax # 601020 <a> 


The f and t constraints represent any floating point stack register - %st and the top of 
the floating point stack respectively. The u constraint represents the second value from the 
top of the floating point stack. 


That's all. You may find more details about x86 64 and general constraints in the official 
documentation. 


Links 


e Linux kernel source code 

e assembly programming language 
e GCC 

e GNU extension 

e Global Descriptor Table 

e Processor registers 

e add instruction 

e flags register 

e x86 64 

e constraints 
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Linux 内 核 开 发 
简介 


如 你 所 知 ， 我 从 去 年 开始 写 了 一 系列 关于 x86_64 架构 汇编 语言 程序 设计 的 博文 。 除 了 大 学 
期 间 写 过 一 些 Hello world 这 样 无 实用 价值 的 程序 之 外 ， 我 从 来 没 写 过 哪怕 一 行 的 底层 代 
码 。 那 些 程序 也 是 很 久 以 前 的 事情 了 ， 就 像 我 刚才 说 的 ， 我 几乎 完全 没有 写 过 底层 代码 。 直 
到 不 久 前 ， 我 才 开 始 对 这 些 事 情感 兴趣 ， 因 为 我 意识 到 我 虽然 可 以 写 出 程序 ， 但 是 我 却 不 知 
道 我 的 程序 是 怎样 被 组 织 运行 的 。 


在 写 了 一 些 汇编 代码 之 后 ， 我 开始 大 致 了 解 了 程序 在 编译 之 后 会 变 成 什么 样子 。 尽 管 如 此 ， 
还 是 有 很 多 其 他 的 东西 我 不 能 够 理解 。 例 如 : 当 syscall 指令 在 我 的 汇编 程序 内 执行 时 究竟 
发 生 了 什么 ， 当 printf 函数 开始 工作 时 又 发 生 了 什么 ， 还 有 ， 我 的 程序 是 如 何 通过 网 络 与 
其 他 计算 机 进行 通信 和 的。 汇编 语言 并 没有 为 这 些 问 题 带 来 答案 ， 于 是 我 决定 做 一 番 深 入 研 

究 。 我 开始 学 习 Linux 内 核 的 源 代码 ， 并 且 尝 试 着 理解 那些 让 我 感 兴 趣 的 东西 。 然 而 Linux 内 
核 源 代码 也 没有 解答 我 所 有 的 问题 ， 不 过 我 自身 关于 Linux 内 核 及 其 外 围 流程 的 知识 确实 掌 
握 的 更 好 了 。 

在 我 开始 学 习 Linux 内 核 的 九 个 半月 之 后 ， 我 写 了 这 部 分 内 容 ， 并 且 发 布 了 本 书 的 第 一 部 

分 。 到 现在 为 止 ， 本 书 共 包括 了 四 个 部 分 ， 而 这 并 不 是 终点 。 我 之 所 以 写 这 一 系列 关于 Linux 
内 核 的 文章 其 实 更 多 的 是 为 了 我 自己 。 你 也 知道 ，Linux 内 核 的 代码 量 极其 巨大 ， 另 外 还 非常 
容易 忘记 这 一 块 或 那 一 块 内 核 代码 做 了 什么 ， 或 者 忘记 某 些 东 西 是 怎么 实现 的 。 出 乎 意料 的 
是 linux-insides 很 快 就 火 了 ， 并 且 在 九 个 月 后 积攒 了 9696 个 星星 : 


© Unwatch ~ 912 会 Star 9,096 Y Fork 674 


看 起 来 人 们 对 Linux 内 核 的 内 在 机 制 非常 的 感 兴 趣 。 除 此 之 外 ， 在 我 写 linux-insides 的 这 
段 时 间 里 ， 我 收 到 了 很 多 人 发 来 的 问题 ， 这 些 问 题 大 都 是 关于 如 何 开始 向 Linux 内 核 贡 献 代 
码 。 通 常 来 说 ， 人 们 是 很 有 兴趣 为 开源 项 目 做 贡献 的 ，Linux 内 核 也 不 例外 : 

Google contribute to linux kernel bes! 
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这 么 看 起 来 大 家 对 Linux 内 核 的 开发 流程 非常 感 兴 趣 。 我 认为 如 果 这 么 一 本 关于 Linux 内 核 的 
书 却 不 包括 一 部 分 来 讲 讲 如 何 参 与 Linux 内 核 开 发 的 话 ， 那 就 非常 奇怪 了 。 这 就 是 我 决定 写 
nn Deb ets 你 应 该 对 贡献 Linux 内 核 感 兴趣 ， 但 是 如 果 
你 想 参与 Linux 内 核 开 发 的 话 ， 那 这 部 分 就 是 为 你 而 作 。 


让 我 们 开始 吧 。 


如 何 入 门 Linux 内 核 
首先 ， 让 我 们 看 看 如 何 获 取 、 构 建 并 运行 Linux 内 核 。 你 可 以 通过 两 种 方式 来 运行 你 自己 定 
制 的 内 核 : 


o 在 虚拟 机 里 运行 Linux 内 核 ; 

o 在 丨 实 的 硬件 上 运行 Linux AK © 
我 会 对 这 两 种 方式 都 展开 描述 。 在 我 们 开始 对 Linux 内 核 做 些 什么 之 前 ， 我 们 首先 需要 先 获 
取 它 。 根 据 你 目的 的 不 同 ， 有 两 种 方式 可 以 做 到 这 一 点 。 如 果 你 只 是 想 更 新 一 下 你 电脑 上 的 
Linux 内 核 版 本 ， 那 么 你 可 以 使 用 特定 于 你 Linux 发 行 版 的 命令 。 


在 这 种 情况 下 ， 你 只 需要 使 用 软件 包 管理 器 下 载 新 版 本 的 Linux 内 核 。 例 如 ， 为 了 将 Ubuntu 
(Vivid Vervet) 系统 的 Linux 内 核 更 新 至 4.1 版 本 ， 你 只 需要 执行 以 下 命令 


$ sudo add-apt-repository ppa:kernel-ppa/ppa 
$ sudo apt-get update 


在 这 之 后 ， 再 执行 下 面 的 命令 : 


$ apt-cache showpkg linux-headers 


然后 选择 你 感 兴 趣 的 Linux 内 核 的 版 本 。 最 后 ， 执行 下 面 的 命令 并 且 将 ${version} 替换 为 你 
从 上 一 条 命令 的 输出 中 选择 的 版 本 号 。 


$ sudo apt-get install linux-headers-${version} linux-headers-${version}-generic linux 


-image-${version}-generic --fix-missing 


最 后 重启 你 的 系统 。 重 启 完成 后 ， 你 将 在 grub 菜单 中 看 到 新 的 内 核 。 


另 一 方面 ， 如 果 你 对 Linux 内 核 开 发 感 兴趣 ， 那 么 你 就 需要 获得 Linux 内 核 的 源 代 码 。 你 可 以 
在 kernel.org 网 站 上 找到 它 并 且 下 载 一 个 包含 了 Linux 内 核 源 代码 的 归档 文件 。 实 际 上 ， 
Linux 内 核 的 开发 流程 完全 建立 在 git 版 本 控制 系统 之 上 ， 所 以 你 需要 通过 git 来 从 
kernel.org 上 获取 内 核 源 代 码 : 


$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 


我 不 知道 你 怎 cet 但 是 我 本 身 是 非常 喜欢 github 的 。 它 上 面 有 一 个 Linux 内 核 主线 仓库 
镜像 ， 你 可 以 通过 以 下 命令 克隆 它 : 


$ git clone git@github.com:torvalds/linux.git 


我 是 用 我 自己 fork 的 仓库 来 进行 开发 的 ， 等 到 我 想 从 主线 仓库 拉 取 更 新 的 时 候 ， 我 只 需要 执 
行 下 方 的 命令 即 可 : 


$ git checkout master 
$ git pull upstream master 


注意 这 个 主线 仓库 的 远程 主机 名 叫做 upstream 。 为 了 将 主线 Linux 仓库 添加 为 一 个 新 的 远程 
主机 ， 你 可 以 执行 


git remote add upstream git@github.com:torvalds/linux.git 


在 此 之 后 ， 你 将 有 两 个 远程 主机 : 


~/dev/linux (master) $ git remote -v 

origin git@github.com:0@xAX/linux.git (fetch) 

origin git@github.com:@xAX/linux.git (push) 

upstream https://github.com/torvalds/linux.git (fetch) 
upstream https://github.com/torvalds/linux.git (push) 


其 中 一 个 远程 主机 是 你 的 fork 仓库 ( origin )， 另 一 个 是 主线 仓库 ( upstream ) ° 


现在 ， 我 们 已 经 有 了 一 份 Linux 内 核 源 代 码 的 本 地 副本 ， 我 们 需要 配置 ee 
核 的 配置 有 很 多 不 同 的 方式 ， 最 简单 的 方式 就 是 直接 拷贝 /boot 目录 下 已 安装 内 核 的 配置 
件 : 


$ sudo cp /boot/config-$(uname -r) ~/dev/linux/.config 


如 果 你 当前 的 内 核 被 编译 为 支持 访问 /proc/config.gz 文件 ， 你 也 可 以 使 用 以 下 命令 复制 当 
前 内 核 的 配置 文件 : 


$ cat /proc/config.gz | gunzip > ~/dev/linux/.config 
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如 果 你 对 发 行 版 维护 者 提供 的 标准 内 核 配置 文件 并 不 满意 ， 你 也 可 以 手动 配置 Linux 内 核 ， 
有 两 种 方式 可 以 做 到 这 一 点 。Linux 内 核 的 根 Makefile 文件 提供 了 一 系列 可 配置 的 目标 选 
项 。 例 如 menuconfig 为 内 核 配置 提供 了 一 个 菜单 界面 : 


Terminal 


Edit View Search Terminal Help 


Linux/x86 4.3.0-rcl Kernel Configuration 
Arrow keys navigate the menu. <Enter> selects submenus ---> (or empty 
submenus ----). Highlighted letters are hotkeys. Pressing <Y> 
includes, <N> excludes, <M> modularizes features. Press <Esc><Esc> to 
exit, <?> for Help, </> for Search. Legend: [*] built-in [ ] 


[h] 64-bit kernel 
General setup ---> 
[*] Enable loadable module support ---> 
-*- Enable the block layer ---> 
Processor type and features ---> 
Power management and ACPI options ---> 
Bus options (PCI etc.) ---> 
Executable file formats / Emulations ---> 
[*] Networking support ---> 
Device Drivers ---> 
4 (+) 


< Exit > < Help > < Save > < Load > 





defconfig 参数 会 为 当前 的 架构 生成 默认 的 内 核 配置 文件 ， 例 如 x86 64 defconfig。 你 可 以 
将 arch 命令 行 参 数 传递 给 make ， 以 此 来 为 给 定 架构 创建 defconfig 配置 文件 : 


$ make ARCH=arm64 defconfig 


allnoconfig 、 allyesconfig 以 及 allmodconfig 参数 也 允许 你 生成 新 的 配置 文件 ， 其 效果 
分 别 为 尽 可 能 多 的 选项 都 关闭 、 尽 可 能 多 的 选项 都 启用 或 尽 可 能 多 的 选项 都 作为 模块 局 
用 。 nconfig 命令 行 参 数 提供 了 基于 ncurses 的 菜单 程序 来 配置 Linux 内 核 : 


720 
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.config - Linux/x86 4.3.0-rcl Kernel Configuration 
86 4.3.0-rcl Kernel Configuration 


[*] 64-bit kernel 


General setup ---> 
[*] Enable loadable module support ---> 
-*- Enable the block layer ---> 

Processor type and features ---> 

Power management and ACPI options ---> 

Bus options (PCI etc.) ---> 

Executable file formats / Emulations ---> 

Networking support ---> 

Device Drivers ---> 

Firmware Drivers ---> 

File systems ---> 

Kernel hacking ---> 

Security options ---> 

Cryptographic API ---> 

Virtualization ---> 

Library routines ---> 
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randconfig 参数 其 至 可 以 随机 地 生成 Linux 内 核 配 置 文件 。 我 不 会 讨论 如 何 去 配 置 Linux 内 

核 或 启用 哪个 选项 ， 因 为 没有 必要 这 么 做 : 首先 ， 我 不 知道 你 的 硬件 配置 ; 其 次 ， 如 果 我 知 
道 了 你 的 硬件 配置 ， 那 么 剩 下 的 问题 就 是 搞 清楚 如 何 使 用 程序 生成 内 核 配置 ， 而 这 些 程序 的 
使 用 都 是 非常 容易 的 。 


好 了 ， 我 们 现在 有 了 Linux 内 核 的 源 代 码 并 且 完 成 了 配置 。 下 一 步 就 是 编译 Linux AKT oR 
简单 的 编译 Linux 内 核 的 方式 就 是 执行 以 下 命令 : 


$ make 


scripts/kconfig/conf --silentoldconfig Kconfig 
# 
# configuration written to .config 
# 
CHK include/config/kernel.release 
UPD include/config/kernel.release 
CHK include/generated/uapi/linux/version.h 
CHK include/generated/utsrelease.h 


OBJCOPY arch/x86/boot/vmlinux.bin 

AS arch/x86/boot/header.o 

LD arch/x86/boot/setup. elf 

OBJCOPY arch/x86/boot/setup.bin 

BUILD arch/x86/boot/bzImage 

Setup is 15740 bytes (padded to 15872 bytes). 
System is 4342 kB 
CRC 82703414 
Kernel: arch/x86/boot/bzImage is ready (#73) 


为 了 增加 内 核 的 编译 速度 ， 你 可 以 给 make 传递 命令 行 参数 -jh ， 这 里 的 N 指定 了 并 发 执 
行 的 命令 数目 : 


$ make -j8 


如 果 你 想 为 一 个 架构 构建 一 个 与 当前 内 核 不 同 的 内 核 ， 那么 最 简单 的 方式 就 是 传递 下 面 两 个 
参数 : 


© ARCH 命令 行 参数 是 目标 架构 名 ; 


© CROSS COMPILER 命令 行 参 数 是 交叉 编译 工具 的 前 组 ; 


例如 ， 如 果 我 们 想 使 用 默认 内 核 配 置 文件 为 arm64 架构 编译 Linux 内 核 ， 我 们 需要 执行 以 下 


命令 : 


$ make -j4 ARCH=arm64 CROSS_COMPILER=aarch64-linux-gnu- defconfig 
$ make -j4 ARCH=arm64 CROSS_COMPILER=aarch64-1linux-gnu- 


编译 的 结果 就 是 你 会 看 到 压缩 后 的 内 核 文件 - arch/x86/boot/bzImage ° 既然 我 们 已 经 编译 好 
TAR? 那么 就 可 以 把 它 安装 到 我 们 的 电脑 上 或 者 只 是 将 它 运 行 在 模拟 器 里 。 


安装 Linux 内 核 


就 像 我 之 前 写 的 ， 我 们 将 考察 两 种 运行 新 内 核 的 方法 : 第 一 种 情况 ， 我 们 可 以 在 丨 实 的 硬件 
上 安装 并 运行 新 版 本 的 Linux 内 核 ， 第 二 种 情况 就 是 在 虚拟 机 上 运行 Linux 内 核 。 在 前 面 的 段 

落 中 我 们 看 到 了 如 何 从 源 代 码 来 构建 Linux 内 核 ， 并且 我 们 现在 已 经 得 到 了 内 核 的 压缩 镜 

像 : 


Kernel: arch/x86/boot/bzImage is ready (#73) 


在 我 们 获得 了 bzimage 之 后 ， 我 们 需要 使 用 以 下 命令 来 为 新 的 Linux 内 核 安装 headers 和 


modules 


$ sudo make headers_install 
$ sudo make modules_install 


以 及 内 核 自身 : 


$ sudo make install 


从 这 时 起 ， 我 们 已 经 安装 好 了 新 版 本 的 Linux 内 核 ， 现 在 我 们 需要 通知 bootloader 新 内 核 已 
经 安装 完成 。 我 们 当然 可 以 手动 编辑 /boot/grub2/grub.cfg 配置 文件 并 将 新 内 核 添 加 进去 ， 
但 是 我 更 推荐 使 用 脚本 来 完成 这 件 事 。 我 现在 在 使 用 两 种 不 同 的 Linux 发 行 版 : Fedora J 
Ubuntu， 有 两 种 方式 可 以 用 来 更 新 grub 配置 文件 ， 我 目前 正在 使 用 下 面 的 脚本 来 达到 这 

ay: 


#!/bin/bash 
source "term-colors" 


DISTRIBUTIVE=$(cat /etc/*-release | grep NAME | head -1 | sed -n -e 'S/NAME\=//p' ) 
echo -e "Distributive: ${Green}${DISTRIBUTIVE}${Color_Off}" 


if [[ "$DISTRIBUTIVE" == "Fedora" ]] ; 
then 

su -c 'grub2-mkconfig -o /boot/grub2/grub.cfg' 
else 

sudo update-grub 
fi 


echo "${Green}Done.${Color_Off}" 


新 Linux 内 核 安装 过 程 中 的 最 后 一 步 ， 在 这 之 后 你 可 以 重启 你 的 电脑 ， 然 后 在 启动 过 程 


这 是 
中 选择 新 版 本 的 内 核 。 
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第 二 种 情况 就 是 在 虚拟 机 内 运行 新 的 Linux 内 核 ， 我 更 倾向 于 使 用 qemu。 首 先 我 们 需要 为 此 
构建 初始 的 虚拟 内 存盘 -initrd。 initrd 是 一 个 临时 的 根 文件 系统 ， 它 在 初始 化 期 间 被 Linux 
内 核 使 用 ， 而 那 时 其 他 的 文件 系统 尚未 被 挂 载 。 我 们 可 以 使 用 以 下 命令 构建 initrd 


首先 我 们 需要 下 载 busybox， 然 后 运行 menuconfig 命令 配置 它 : 


FAA FF F 


mkdir initrd 

cd initrd 

curl http://busybox.net/downloads/busybox-1.23.2.tar.bz2 | tar xjf - 
cd busybox-1.23.2/ 

make menuconfig 

make -j4 


busybox 是 一 个 可 执行 文件 - /bin/busybox ， 它 包括 了 一 系列 类 似 于 coreutils 的 标准 工具 。 
在 busysbox 菜单 界面 上 我 们 需要 启用 Build BusyBox as a static binary (no shared libs) 
选项 : 


File 
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Rikid Options 
Arrow keys navigate the menu. <Enter> selects submenus --->. 
Highlighted letters are hotkeys. Pressing <Y> includes, <N> excludes, 
<M> modularizes features. Press <Esc><Esc> to exit, <?> for Help, </> 
for Search. Legend: [*] built-in [ ] excluded <M> module < > 


[i] Build BusyBox as a static binary (no shared libs) (NEW) 

[ ] “uild BusyBox as a position independent executable (NEW) 

[ ] orce NOMMU build (NEW) 

[ ] uild shared libbusybox (NEW) 

*] uild with Large File Support (for accessing files > 2 GB) (NEW) 
) ross Compiler prefix (NEW) 

) ath to sysroot (NEW) 

) dditional CFLAGS (NEW) 

) dditional LDFLAGS (NEW) 

) dditional LDLIBS (NEW) 


[ 
( 
( 
( 
( 
( 


<Select < Exit > < Help > 


我 们 可 以 按照 下 方 的 路 径 找到 这 个 菜单 项 : 


Busybox Settings 
--> Build Options 


之 后 ， 我 们 从 busysbox 的 配置 菜单 退出 去 ， 然 后 执行 下 面 的 命令 来 构建 并 安装 它 : 





724 


$ make -j4 
$ sudo make install 


既然 busybox 已 经 安装 完了 ， 那 么 我 们 就 可 以 开始 构建 initrd 了 。 为 了 完成 构建 过 程 ， 我 
们 需要 返回 到 之 前 的 initrd 目录 并 且 运行 命令 : 


co 

mkdir -p initramfs 

cd initramfs 

mkdir -pv {bin,sbin,etc,proc,sys,usr/{bin,sbin}} 
cp -av ../busybox-1.23.2/_install/* . 


HH fF Ff fF 


这 会 把 busybox 复制 到 bin 目录 、 sbin 目录 以 及 其 他 相关 目录 内 。 现 在 我 们 需要 创建 可 
执行 的 init 文件 ， 该 文件 将 会 在 系统 内 作为 第 一 个 进程 执行 。 我 的 init 文件 仅仅 挂 载 了 
procfs 和 sysfs 文件 系统 并 且 执 行 了 shell 程序 : 


#!/bin/sh 


mount -t proc none /proc 
mount -t sysfs none /sys 


exec /bin/sh 


最 后 ， 我 们 创建 一 个 归档 文件 ， 这 就 是 我 们 的 initrd 了 : 


$ find . -printO | cpio --null -ov --format=newc | gzip -9 > ~/dev/initrd_x86_64.gz 


我 们 现在 可 以 在 虚拟 机 里 运行 内 核 了 。 就 像 我 之 前 写 过 的 ， 我 偏向 于 使 用 qemu 来 完成 这 些 
工作 ， 下 面 的 命令 可 以 用 来 运行 我 们 的 Linux 内 核 : 


$ qemu-system-x86_64 -snapshot -m 8GB -serial stdio -kernel ~/dev/linux/arch/x86_64/bo 
ot/bzImage -initrd ~/dev/initrd_x86_64.gz -append "root=/dev/sda1 ignore_loglevel" 


QEMU x 


Machine View 


linuxrc root 
proc sbin 





从 现在 起 ， 我 们 就 可 以 在 虚拟 机 内 运行 Linux 内 核 了 ， 这 意味 着 我 们 可 以 开始 对 内 核 进行 修 
改 和 测试 了 9 


除了 上 面 的 手动 过 程 之 外 ， 还 可 以 考虑 使 用 来 自动 生成 initrd 。 
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这 部 分 的 核心 内 容 主 要 回答 了 两 个 问题 : 在 你 发 送 第 一 个 Linux 内 核 补丁 之 前 你 应 该 做 什么 
( to do ) 和 不 能 做 什么 ( not to do )。 请 千 万 不 要 把 应 该 做 的 事 ( to do) 和 待 办 事项 

( todo ) 搞 混 了 。 我 无 法 回答 你 能 为 Linux 内 核 修复 什么 问题 ， 我 只 是 想 告诉 你 我 拿 Linux 内 
核 源 代码 做 实验 的 过 程 。 


首先 ， 我 需要 使 用 以 下 命令 从 Linus 的 仓库 中 拉 取 最 新 的 更 新 : 


$ git checkout master 
$ git pull upstream master 


在 这 之 后 ， 我 的 本 地 Linux 内 核 源 代码 仓库 已 经 和 仓库 同步 了 。 现 在 我 们 可 以 在 源 代码 
上 做 些 修改 了 。 就 像 我 之 前 写 E n iy: > 我 并 不 能 给 你 太 多 
建议 。 不 过 ， 对 于 新 手 来 说 最 好 的 地 方 就 是 staging 源码 树 ， 也 就 是 上 的 驱 
动 集合 。 staging 源码 树 的 主要 维护 者 是 ， 该 源码 树 正 是 你 的 琐 态 补丁 
可 以 被 接受 的 地 方 。 让 我 们 看 一 个 简单 的 例子 ， 该 例子 描述 了 如 何 生 成 补丁 、 检 查 补 丁 以 及 
如 何 将 补丁 发 送 到 o 


如 果 我 们 查看 一 下 为 Digi International EPCA PCI 基础 设备 所 写 的 驱动 程序 ， 在 295 行 我 们 
将 会 看 到 dgap_sindex 函数 : 


static char *dgap_sindex(char *string, char *group) 


{ 
char *ptr; 
if (!string || !group) 
return NULL; 
HOGG) string SEENINGE) A 
for (ptr = group; *ptr; ptr++) { 
if (*ptr == *string) 
return string; 
} 
} 
return NULL; 
} 


这 个 函数 查找 group 和 string 共有 的 字符 并 返回 其 位 置 j 在 研究 Linux 内 核 源 代码 期 间 ， 
我 注意 到 lib/string.c 文件 里 实现 了 一 个 strpbrk 函数 ， 该 函数 和 dgap_sinidex Hik T F] 
样 的 事 。 使 用 现存 函数 的 另 一 种 自 定义 实现 并 不 是 一 个 好 主意 ， 所 以 我 们 可 以 从 
drivers/staging/dgap/dgap.c 源码 文件 中 移 除 dgap_sindex 函数 并 使 用 strpbrk 替换 它 。 


首先 ， 让 我 们 基于 当前 主 分 支 创建 一 个 新 的 git TL’ ATLA Linux 内 核 主 仓库 同步 : 


$ git checkout -b "dgap-remove-dgap_sindex" 


然后 ， 我 们 可 以 将 dgap_sindex 函数 替换 为 strpbrk ° 做 完 这 些 修改 之 后 ， 我 们 需要 重新 编 
译 Linux 内 核 或 者 只 重 编译 dgap 目录 。 不 要 忘 了 在 内 核 配置 文件 中 启用 这 个 驱动 ， 你 可 以 在 
如 下 位 置 找到 该 驱动 : 


Device Drivers 
--> Staging drivers 
----> Digi EPCA PCI products 


Terminal 


File Edit View Search Terminal Help 


Staging drivers 
Arrow keys navigate the menu. <Enter> selects submenus ---> (or empty 
submenus ----). Highlighted letters are hotkeys. Pressing <Y> 
includes, <N> excludes, <M> modularizes features. Press <Esc><Esc> to 
exit, <?> for Help, </> for Search. Legend: [*] built-in [ ] 
t(-) 
Android ---- 
GCT GDM72xx WiMAX support ---- 
GCT GDM724x LTE support 
Lustre file system client support 
Digi Neo and Classic PCI Products 
Digi EPCA PCI products 
Xilinx FPGA firmware download module 
Skein digest algorithm 
Unisys SPAR driver support ---- 
Support for small TFT LCD display modules ---- 


< 
< 
< 
< 
< 
< 
< 
[ 
< 
: 


< Exit > < Help > < Save > < Load > 





现在 是 时 候 提交 修改 了 ， 我 使 用 下 面 的 命令 组 合 来 完成 这 件 事 : 


$ git add. 
$ git commit -s -v 


最 后 一 条 命令 运行 后 将 会 打开 一 个 编辑 器 ， 该 编辑 器 会 从 $6IT_EDITOR 或 $EDITOR 环境 变 
量 中 进行 选择 。 -s 命令 行 BE 数 会 在 提交 信息 的 末尾 按照 是 交 者 名 字 加 上 一 行 Signed-off- 
的 最 后 


by 。 你 在 每 一 条 提交 信息 都 能 看 到 这 一 行 ， 例 如 - Ee 这 一 行 的 主要 目的 是 追 
踪 谁 做 的 修改 。 -v 选项 按照 合并 格式 显示 HEAD 提交 和 即将 进行 的 最 新 提交 之 间 的 差异 。 
这 样 做 不 是 并 必须 的 ， 但 有 时 候 却 很 有 用 。 再 来 说 下 提交 人 信息， 实际 上 ， 一 条 提交 信息 由 两 
部 分 组 成 : 


第 一 部 分 放 在 第 一 行 ， 它 包括 了 一 名 对 所 做 修改 的 简短 描述 。 这 一 行 以 [PATCH] up ， 后 
面 跟 上 子 系统 、 驱 动 或 架构 的 名 字 ， 以 及 在 ; 之 后 的 简 述 信息 。 在 我 们 这 个 例子 中 ， 这 一 行 
信 息 如 下 所 示 : 


[PATCH] staging/dgap: Use strpbrk() instead of dgap_sindex() 


在 简 述 信息 之 后 ， 我 们 通常 空 一 行 再 加 上 对 本 次 提交 的 详尽 描述 。 在 我 们 的 这 个 例子 中 ， 这 
些 信 息 如 下 所 示 : 


The <linux/string.h> provides strpbrk() function that does the same that the 
dgap_sindex(). Let's use already defined function instead of writing custom. 


在 提交 信息 的 最 后 是 Sign-off-by 这 一 行 。 注 意 ， 提 交 信 息 的 每 一 行 不 能 超过 86 个 字符 并 
且 提 交 信 息 必须 详细 地 描述 你 所 做 的 修改 。 千 万 不 要 只 写 一 条 类 似 于 custom function 
removed 这 样 的 信息 ， 你 需要 描述 你 做 了 什么 以 及 为 什么 这 样 做 。 补 丁 的 审核 者 必须 据 此 知道 
他 们 正在 审核 什么 内 容 ， 除 此 之 外 ， 这 里 的 提交 信息 本 身 也 非常 有 用 。 每 当 你 不 能 理解 一 些 
东西 的 时 候 ， 我 们 都 可 以 使 用 git blame 命令 来 阅读 关于 修改 的 描述 。 


提交 修改 之 后 ， 是 时 候 生成 补丁 文件 了 。 我 们 可 以 使 用 format-patch 命令 来 完成 : 


$ git format-patch master 
0001-staging-dgap-Use-strpbrk-instead-of-dgap_sindex.patch 


我 们 把 分 支 名 字 (这 里 是 master ) 传递 给 format-patch 命令 ， 该 命令 会 根据 那些 包括 在 
dgap-remove-dgap_sindex 分 支 但 不 在 master 分 支 的 最 新 改动 来 生成 补丁 。 你 会 发 现 ， 
format-patch 命令 生成 的 文件 包含 了 最 新 所 做 的 修改 ， 该 文件 的 名 字 是 基于 提交 信息 的 简 述 
来 生成 的 。 如 果 你 想 按照 自 定义 的 文件 名 来 生成 补丁 ， 你 可 以 使 用 --stdout 选项 : 


$ git format-patch master --stdout > dgap-patch-1.patch 


最 后 一 步 就 是 在 我 们 生成 补丁 之 后 EM 
的 邮件 客户 端 ， 不 过 git 为 此 提供 了 一 个 专门 的 命令 : git send-email 。 在 发 送 补丁 之 
前 ， 你 需要 知道 发 到 哪里 。 虽 然 你 可 以 ee linux-kernel@vger.kernel.org 这 个 
邮件 列表 ， 但 这 很 可 能 让 你 的 补丁 因为 巨大 的 消息 流 而 被 忽略 掉 。 最 好 的 选择 是 将 补丁 发 送 
到 你 的 修改 所 属 子 系统 的 维护 者 那里 。 你 可 以 使 用 get_maintainer.pl 这 个 脚本 来 找到 这 些 
维护 者 的 名 字 。 你 所 需要 做 的 就 是 将 你 代码 所 在 的 文件 或 目录 作为 参数 传递 给 脚本 。 


$ ./scripts/get_maintainer.pl -f drivers/staging/dgap/dgap.c 

Lidza Louina <lidza.louina@gmail.com> (maintainer:DIGI EPCA PCI PRODUCTS) 
Mark Hounschell <markh@compro.net> (maintainer:DIGI EPCA PCI PRODUCTS) 
Daeseok Youn <daeseok.youn@gmail.com> (maintainer :DIGI EPCA PCI PRODUCTS) 
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (Supporter:STAGING SUBSYSTEM) 
driverdev-devel@linuxdriverproject.org (open list:DIGI EPCA PCI PRODUCTS) 
devel@driverdev.osuosl.org (open list:STAGING SUBSYSTEM) 
linux-kernel@vger.kernel.org (open list) 


你 将 会 看 到 一 组 姓名 和 与 之 相关 的 邮件 地 址 。 现 在 你 可 以 通过 下 面 的 命令 发 送 补丁 了 : 


$ git send-email --to "Lidza Louina <lidza.louina@gmail.com>" \ 
--cc "Mark Hounschell <markh@compro.net>" 
--cc "Daeseok Youn <daeseok.youn@gmail.com>" 
--cc "Greg Kroah-Hartman <gregkh@linuxfoundation.org>" 
--cc "driverdev-devel@linuxdriverproject.org" 


BE a a 


--cc "devel@driverdev.osuosl.org" 
--cc "linux-kernel@vger.kernel.org" 


这 就 是 全 部 的 过 程 。 补 丁 被 发 出 去 了 ， 现 在 你 所 需要 做 的 就 是 等 待 Linux 内 核 开 发 者 的 反 

馈 。 在 你 发 送 完 补 丁 并 且 维 护 者 接受 它 之 后 ， 你 将 在 维护 者 的 仓库 中 看 到 它 (例如 前 文 你 看 到 
的 补丁 )。 一 段 时 间 后 ， 维 护 者 将 会 向 Linus 发 送 一 个 拉 取 请 求 ， 之 后 你 就 会 在 主线 仓库 里 看 
到 你 的 补丁 了 。 


这 就 是 全 部 内 容 。 


想 给 你 一 些 建议 ， 这 些 建议 大 都 是 关于 在 Linux 内 核 的 开发 过 程 中 需要 


。 考虑 ， 考 虑 ， 再 考虑 。 在 你 决定 发 送 补丁 之 前 再 三 考虑 。 


© 在 你 每 次 改 完 Linux 内 核 源 代码 之 后 - 试 着 编译 它 。 我 指 的 是 任何 修改 之 后 ， 都 要 不 断 的 
编译 。 没 有 人 喜欢 那些 连 编译 都 不 通过 修改 。 


。 Linux 内 核 有 一 套 代 码 规范 指南 ， 你 需要 遵守 它 。 有 一 个 很 棒 的 脚本 可 以 帮 你 检查 所 做 的 
修改 。 这 个 脚本 就 是 - scripts/checkpatch.pl。 只 需要 将 被 改动 的 源码 文件 传递 给 它 即 
可 ， 然 后 你 就 会 看 到 如 下 输出 : 


$ ./scripts/checkpatch.pl -f drivers/staging/dgap/dgap.c 
WARNING: Block comments use * on subsequent lines 
#94: FILE: drivers/staging/dgap/dgap.c:94: 


+/* 

+ SUPPORTED PRODUCTS 

CHECK: spaces preferred around that '|' (ctx:VxV) 

#143: FILE: drivers/staging/dgap/dgap.c:143: 

+ { PPCM, PCI_DEV_XEM_NAME, 64, (T_PCXM|T_PCLITE|T_PCIBUS) }, 


在 git ditt 命令 的 帮助 下 ， 你 也 会 看 到 一 些 有 问题 的 地 方 : 


~/dev/linux $ git diff 
diff --git a/init/main.c b/init/main.c 

index 9e64d70..af379a5 100644 

--- a/init/main.c 

+++ b/init/main.c 


EXPORT SYMBOL(reset devices); 
static int init set reset devices(char *str) 


{ 


reset devices = 1; 


return 1; 





e Linus 不 接受 github pull requests 


o 如 果 你 的 修改 是 由 一 些 不 同 的 且 不 相关 的 改动 所 组 成 的 ， 你 需要 通过 分 离 提 3 — 修 
改 。 git format-patch “P 命令 将 会 为 每 个 提交 生成 一 个 补丁 ， 每 个 补丁 的 标题 会 包含 一 个 
w 前 级， 其 中 N 是 补丁 的 编号 。 eR eee eA ， 也许 给 git format- 
patch 命令 传递 --cover-letter 选项 会 对 此 很 有 帮助 。 这 会 生成 一 个 附加 文件 ， 该 文件 
包括 的 附 函 可 以 用 来 描述 你 的 补丁 集 所 做 的 改动 。 在 git send-email 命令 中 使 用 --in- 
reply-to 选项 也 是 一 个 好 主意 ， 对 附 函 的 回复 发 送出 去 。 对 
于 维护 者 来 说 ， 你 补丁 集 的 结构 看 起 来 就 像 下 面 这 


|--> cover letter 
|----> patch 1 
|----> patch 2 


你 可 以 将 message-id 参数 传递 给 --in-reply-to 选项 ， 该 选项 可 以 在 git send-email 命 
令 的 输出 中 找到 。 


有 一 件 非常 重要 的 事 ， 那 就 是 你 的 邮件 必须 是 纯 文 本 格式 。 通 常 来 说 ， send-email 和 
format-patch 这 两 个 命令 在 内 核 开发 中 都 是 非常 有 用 的 ， 所 以 请 查阅 这 些 命令 的 的 相关 文 
档 ， 你 会 发 现 很 多 有 用 的 选项 ， 例 如 : git send-email 和 git format-patch ° 


© 如 果 你 发 完 补丁 之 后 没有 得 到 立即 答复 ， 请 不 要 惊讶 ， 因 为 维护 者 们 都 是 很 忙 的 。 


e scripts 目录 包含 了 很 多 对 Linux 内 核 开 发 有 用 的 脚本 。 我 们 已 经 看 过 此 目录 中 的 两 个 脚 
RT: checkpatch.pl 和 get_maintainer.pl ° 除 此 之 外 ， 你 还 可 以 找到 stackusage 脚 
本 ， 它 可 以 打印 栈 的 使 用 情况 ，extract-vmlinux 脚本 可 以 提取 出 未 经 压缩 的 内 镜 镜 像 ， 
还 有 很 多 其 他 的 脚本 。 在 scripts 目录 之 外 ， 你 也 会 发 现 很 多 有 用 的 脚 木 ， 这 些 脚本 是 
Lorenzo Stoakes 为 内 核 开发 而 编写 的 。 


e 订阅 Linux 内 核 邮 件 列表 。 ikm 列表 中 每 天 都 会 有 大 量 的 信件 ， 但 是 阅读 它们 并 了 解 一 
些 类 似 于 Linux 内 核 目 前 开发 状态 的 内 容 是 很 有 帮助 的 。 除 了 ikm 之 外 ， 还 有 一 些 其 
他 的 邮件 列表 ， 它 们 分 别 对 应 于 不 同 的 Linux 内 核子 系统 。 


o 如 果 你 发 的 补丁 第 一 次 没有 被 接受 ， 你 就 会 收 到 Linux 内 核 开发 者 的 反馈 。 请 做 一 些 修 
改 然 后 以 [PATCH vN] ( N 是 补丁 版 本 号 ) 为 前 缓 重新 发 送 补丁 ， 例 如 : 


[PATCH v2] staging/dgap: Use strpbrk() instead of dgap_sindex() 


同样 的 ， 这 次 的 补丁 也 必须 包括 更 新 日 志 以 便 描 述 自 上 一 次 的 补丁 以 来 所 做 的 修改 。 当 然 ， 
本 文 并 不 是 对 Linux 内 核 开 发 详尽 无 遗 的 指导 清单 ， 但 是 一 些 最 重要 的 事项 已 经 都 被 阅 明 
了 。 


Happy Hacking! 


Linux 内 核 开 发 


N 


D 


有 


结 


wp 


¢ 


我 布 望 这 篇 文章 能 够 帮助 其 他 人 加 入 Linux 内 核 社 区 | 如 果 你 有 其 他 问题 或 建议 ， 可 以 给 我 
写 邮 件 或 者 在 Twitter 上 联系 我 。 


请 注意 ， 美 语 并 不 是 我 的 母语 ， 对 此 带 来 的 不 便 我 感到 很 抱歉 。 如 果 你 发 现 了 错误 ， 请 通过 
邮件 或 发 PR 来 通知 我 。 


相关 链接 


e blog posts about assembly programming for x86 64 
e Assembler 

e distro 

e package manager 

e grub 

e kernel.org 

e version control system 

e arm64 

e bzlmage 

e qemu 

e initrd 

e busybox 

è coreutils 

e procfs 

e sysfs 

e Linux kernel mail listing archive 

e Linux kernel coding style guide 

e How to Get Your Change Into the Linux Kernel 
e Linux Kernel Newbies 

e plain text 


132 


你 知道 Linux 内 核 是 如 何 构 建 的 吗 ? 


介绍 


我 不 会 告诉 你 怎么 在 自己 的 电脑 上 去 构建 、 安 装 一 个 定制 化 的 Linux 内 核 ， 这 样 的 资料 太 多 
了 ， 它 们 会 对 你 有 帮助 。 本 文 会 告诉 你 当 你 在 内 核 源码 路 径 里 训 下 make 时 会 发 生 什么 


当 我 刚刚 开始 学 习 jaa > Makefile 是 我 打开 的 第 一 个 文件 ， 这 个 文件 看 起 来 巾 令 人 定 
怕 :)。 那 时 候 这 个 Makefile 还 只 包含 了 1591 行 代码 ， 当 我 开始 写本 文 时 ， 内 核 已 经 是 4.2.0 
的 第 三 个 候选 版 本 了 。 


ee en a 
， 但 是 如 果 你 已 经 读 过 内 核 源 代码 ， 你 就 会 发 现 每 个 包含 代码 的 目录 都 有 一 个 自己 的 
ge 编译 链接 的 ， 所 以 我 们 将 只 会 挑选 
一 些 通 用 的 例子 来 说 明 问 题 。 而 你 不 会 在 这 里 找到 构建 内 核 的 文档 、 如 何 整 洁 内 核 代码 、 
tags 的 生成 和 交叉 编译 相关 的 说 明 ， 等 等 。 我 们 将 从 make 开始 ， 使 用 标准 的 内 核 配 置 文 

件 ， 到 生成 了 内 核 镜像 bzimage 结束 。 


如 果 你 已 经 很 了 解 make 工具 ， 那 是 最 好 ， 但 是 我 也 会 描述 本 文 出 现 的 相关 代码 。 


让 我 们 开始 吧 ! 
编译 内 核 前 的 准备 


在 开始 编译 前 要 进行 很 多 准备 工作 。 最 主要 的 就 是 找到 并 配置 好 配置 文件 ，make 命令 要 使 
用 到 的 参数 都 需要 从 这 些 配置 文件 获取 。 现 在 就 让 我 们 深入 内 核 的 根 Makefile 吧 。 


内 核 的 根 makefile 负责 构建 两 个 主要 的 文件 : vmlinux (内 核 镜像 可 执行 文件 ) 和 模块 文 
件 。 内 核 的 Makefile 从 定义 如 下 变量 开始 : 


VERSION = 4 

PATCHLEVEL = 2 

SUBLEVEL = 0 

EXTRAVERSION = -rc3 

NAME = Hurr durr I'ma sheep 


这 些 变量 决定 了 当前 内 核 的 版 本 ， 并 且 被 使 用 在 很 多 不 同 的 地 方 ， 比 如 同一 个 Makefile 中 


的 KERNELVERSION 


KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL), .$(PATCHLEVEL)$(if $(SUBLEVEL), .$(SUBLEVE 
L)))$(EXTRAVERSION) 


接 下 来 我 们 会 看 到 很 多 ifeq 条 件 判断 语句 ， 它 们 负责 检查 传递 给 make 的 参数 。 内 核 的 
Makefile 提供 了 一 个 特殊 的 编译 选项 make help ， 这 个 选项 可 以 生成 所 有 的 可 用 目标 和 一 
些 能 传 给 make 的 有 效 的 命令 行 参 数 。 举 个 例子 ， make V=1 会 在 构建 过 程 中 输出 详细 的 编 
译 信 息 ， 第 一 个 ifeq 就 是 检查 传递 给 make 的 v=n 选项 。 


ifeq ("$(origin V)", "command line") 
KBUILD_VERBOSE = $(V) 

endif 

ifndef KBUILD_VERBOSE 
KBUILD_VERBOSE = 0 

endif 


ifeq ($(KBUILD_VERBOSE),1) 
quiet = 
Q = 
else 
quiet=quiet_ 
Q=@ 


endif 


export quiet Q KBUILD_VERBOSE 


如 果 ven 这 个 选项 传 给 了 make ， 系 统 就 会 给 变量 KBUILD_ VERBOSE 选项 附 上 v Hf S 
则 的 话 ， KBUILD_VERBOSE 就 会 为 9 。 然 后 系统 会 检查 kBUILD_VERBOSE 的 值 ， 以 此 来 决定 
quiet 和 q 的 值 。 符 号 @ 控制 命令 的 输出 ， 如 果 它 被 放 在 一 个 命令 之 前 ， 这 条 命令 的 输 
出 将 会 是 cc scripts/mod/empty.o ， 而 不 是 Compiling .... scripts/mod/empty.o (LCTT 译 
注 : CC 在 Makefile 中 一 般 都 是 编译 命令 ) 。 在 这 段 最 后 ， 系 统 导 出 了 所 有 的 变量 。 


下 一 个 ifeq 语句 检查 的 是 传递 给 make 的 选项 0=/dir ， 这 个 选项 允许 在 指定 的 目录 dir 
输出 所 有 的 结果 文件 : 


ifeq ($(KBUILD_SRC), ) 


ifeq ("$(origin 0)", "command line") 
KBUILD_OUTPUT := $(0) 
endif 


ifneq ($(KBUILD_OUTPUT), ) 
saved-output := $(KBUILD_OUTPUT ) 
KBUILD_OUTPUT := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) \ 
&& /bin/pwd) 
$(if $(KBUILD_OUTPUT),, \ 
$(error failed to create output directory "$(saved-output)")) 


sub-make: FORCE 
$(Q)$(MAKE) -C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR) \ 
-f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS) ) 


skip-makefile := 1 
endif # ifneq ($(KBUILD_OUTPUT), ) 
endif # ifeg ae UILD_SRC), ) 


系统 会 检查 变量 kBUILD SRC ， 它 代表 内 核 代码 的 顶层 目录 ， 如 果 它 是 空 的 (第 一 次 执行 
makefile 时 总 是 空 的 ) ， 我 们 会 设置 变量 kBUILD_0UTPUT 为 传递 给 选项 0 的 值 (如 果 这 个 
选项 被 传 进来 了 ) 。 下 一 步 会 检查 变量 kBUILD_0UTPUT ， 如 果 已 经 设置 好 ， 那 么 接 下 来 会 做 
以 下 几 件 事 : 


e 将 变量 KBUILD_OUTPUT 的 值 保存 到 临时 变量 saved-output ; 

e 尝试 创建 给 定 的 输出 目录 ; 

。 检查 创建 的 输出 目录 ， 如 果 失 败 了 就 打印 错误 ; 

e 如 果 成 功 创建 了 输出 目录 ， 那 么 就 在 新 目录 重新 执行 make 命令 (参见 选项 -c ) 。 


下 一 个 ifeq 语句 会 检查 传递 给 make 的 选项 c 和 m 


ifeq ("$(origin C)", "command line") 
KBUILD_CHECKSRC = $(C) 

endif 

ifndef KBUILD_CHECKSRC 
KBUILD_CHECKSRC = 0 

endif 


ifeq ("$(origin M)", "command line") 
KBUILD_EXTMOD := $(M) 
endif 


第 一 个 选项 c 会 告诉 makefile 需要 使 用 环境 变量 scheck 提供 的 工具 来 检查 全 部 c R 
码 ， 上 默认 情况 下 会 使 用 sparse 。 第 二 个 选项 M 会 用 来 编译 外 部 模块 (本文 不 做 讨论 ) © 


N 


统 还 会 检查 变量 KBUILD_SRC ， 如 果 KBUILD SRC 没有 被 设置 ， 系 统 会 设置 变量 srctree 


了 


X 


ifeq ($(KBUILD_SRC), ) 


srctree :=. 
endif 
objtree = 
src = $(srctree) 
obj = $(objtree) 


export srctree objtree VPATH 


这 将 会 告诉 Makefile 内 核 的 源码 树 就 在 执行 make 命令 的 目录 ， 然 后 要 设置 objtree 和 其 
他 变量 为 这 个 目录 ， 并 且 将 这 些 变量 导出 。 接 着 就 是 要 获取 sUBARCH 的 值 ， 这 个 变量 代表 了 
当前 的 系统 架构 (LCTT 译注 : 一 般 都 指 CPU 架构 ) 


SUBARCH := $(shell uname -m | sed -e S/i.86/x86/ -e S/x86_64/x86/ \ 
-e s/sun4u/sparc64/ \ 
-e s/arm.*/arm/ -e s/saii0/arm/ \ 
-e S/S390x/s390/ -e s/parisc64/parisc/ \ 
-e S/ppc.*/powerpc/ -e s/mips.*/mips/ \ 
-e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ ) 


如 你 所 见 ， 系 统 执行 uname 得 到 机 器 、 操 作 系统 和 架构 的 信息 。 因 为 我 们 得 到 的 是 uname 
的 输出 ， 所 以 我 们 需要 做 一 些 处理 再 赋 给 变量 SuBARCH 。 获 得 SuBARCH 之 后 就 要 设 

HL SRCARCH 和 hfr-arch ， SRCARCH 提供 了 硬件 架构 相关 代码 的 目录 ， hfr-arch 提供 了 相 
关头 文件 的 目录 : 


ifeq ($(ARCH), i386) 
SRCARCH := x86 

endif 

ifeq ($(ARCH),x86_64) 
SRCARCH := x86 

endif 


hdr-arch := $(SRCARCH) 


注意 : ARCH 是 SUBARCH 的 别名 。 如 果 没 有 设置 过 代表 内 核 配 置 文件 路 径 的 变量 
KCONFIG_CONFIG ， 下 一 步 系统 会 设置 它 ， 默 认 情 况 下 就 是 config 


KCONFIG_CONFIG ?= .config 
export KCONFIG_CONFIG 


以 及 编译 内 核 过 程 中 要 用 到 的 shell 


CONFIG SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ 
else if [ -x /bin/bash ]; then echo /bin/bash; \ 
elise echo! sh fil; fa!) 


接 下 来 就 要 设置 一 组 和 编译 内 核 的 编译 器 相关 的 变量 。 我 们 会 设置 主机 的 c 和 c++ 的 编译 
器 及 相关 配置 项 : 


HOSTCC = gcc 

HOSTCXX = g++ 

HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -02 -fomit-frame-pointer 
-std=gnu89 


HOSTCXXFLAGS = -02 


接 下 来 会 去 适 配 代 表 编 译 器 的 变量 cc ， 那 为 什么 还 要 HosT* 这 些 变 量 呢 ? 这 是 因为 cc 
是 编译 内 核 过 程 中 要 使 用 的 目标 架构 的 编译 器 ， 但 是 HosTcc 是 要 被 用 来 编译 一 组 host 程 
序 的 (下 面 我 们 就 会 看 到 ) 。 


然后 我 们 就 看 到 变量 kBUILD MODULES 和 KBUILD_BUILTIN 的 定义 ， 这 两 个 变量 决定 了 我 们 要 
编译 什么 东西 ( 内核 、 模 块 或 者 两 者 ) 


KBUILD_MODULES := 
KBUILD_BUILTIN : 


lI 
ji 


ifeq ($(MAKECMDGOALS), modules) 
KBUILD_BUILTIN := $(if $(CONFIG_MODVERSIONS), 1) 
endif 


在 这 我 们 可 以 看 到 这 些 变量 的 定义 ， 并 且 ， 如 果 们 仅仅 传递 了 modules 给 make ， 变 量 


KBUILD_BUILTIN 会 依赖 于 内 核 配 置 选项 CONFIG MODVERSIONS ° 


下 一 步 操作 是 引入 下 面 的 文件 : 


include scripts/Kbuild.include 


文件 Kbuild 或 者 又 叫做 Kernel Build System 是 一 个 用 来 管理 构建 内 核 及 其 模块 的 特殊 框 
Ro Kbuild 文件 的 语法 与 Makefile —## ° 4 scripts/Kbuild.include A kbuild 系统 提供 
了 一 些 常规 的 定义 。 因 为 我 们 包含 了 这 个 kbuild 文件 ， 我 们 可 以 看 到 和 不 同 工 具 关联 的 这 
些 变量 的 定义 ， 这 些 工具 会 在 内 核 和 模块 编译 过 程 中 被 使 用 (比如 链接 器 、 编 译 器 、 来 自 
binutils 的 二 进 制 工具 包 ) 


AS = $(CROSS_COMPILE)as 
LD = $(CROSS_COMPILE)1d 
CC = $(CROSS_COMPILE)gcc 


CPP = $(€C) E 


AR = $(CROSS_COMPILE)ar 
NM = $(CROSS_COMPILE)nm 
STRIP = $(CROSS_COMPILE)strip 
OBJCOPY = $(CROSS_COMPILE)objcopy 
OBJDUMP = $(CROSS_COMPILE)objdump 
AWK = awk 
在 这 些 定 义 好 的 变量 后 面 ， 我 们 又 定义 了 两 个 变量 : USERINCLUDE 和 LINUXINCLUDE ° Aef] 


包含 了 ee ee errr 


USERINCLUDE := \ 
-I$(srctree)/arch/$(hdr-arch)/include/uapi \ 
-Iarch/$(hdr-arch)/include/generated/uapi \ 
-I$(srctree)/include/uapi \ 
-Iinclude/generated/uapi \ 

-include $(srctree)/include/linux/kconfig.h 


LINUXINCLUDE := \ 
-I$(srctree)/arch/$(hdr-arch)/include \ 


以 及 给 C 编译 器 的 标准 标志 : 


KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ 
-fno-strict-aliasing -fno-common \ 
-Werror-implicit-function-declaration \ 
-Wno-format-security \ 

-std=gnu8s9 


这 并 不 是 最 终 确定 的 编译 器 标志 ， 它 们 还 可 以 在 其 他 Makefile 里 面 更 新 (比如 arch/ 里 面 
的 Kbuild ) 。 变 量 定义 完 之 后 ， 全 部 会 被 导出 供 其 他 Makefile 使 用 。 


下 面 的 两 个 变量 RCS_FIND IGNORE 和 RCS_TAR_IGNORE 包含 了 被 版 本 控制 系统 忽略 的 文件 : 


export RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -0 \ 
-name CVS -o -name .pc -o -name .hg -o -name .git \) \ 
-prune -0 
export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn \ 
--exclude CVS --exclude .pc --exclude .hg --exclude .git 


这 就 是 全 部 了 ， 我 们 已 经 完成 了 所 有 的 准备 工作 ， 下 一 个 点 就 是 如 何 构建 vmlinux ° 


直面 内 核 构建 


现在 我 们 已 经 完成 了 所 有 的 准备 工作 ， 根 Makefile ( 注 : 内 核 根 目录 下 的 Makefile ) 的 下 一 
步 工作 就 是 和 编译 内 核 相关 的 了 。 在 这 之 前 ， 我 们 不 会 在 终端 看 到 make 命令 输出 的 任何 东 
西 。 但 是 现在 编译 的 第 一 步 开始 了 ， 这 里 我 们 需要 从 内 核 根 Makefile 的 598 行 开 始 ， 这 里 可 
以 看 到 目标 vmlinux 


all: vmlinux 
include arch/$(SRCARCH)/Makefile 


不 要 操心 我 们 略 过 的 从 export RCS_FIND_IGNORE..... 到 all: vmlinux..... 这 一 部 分 
Makefile 代码 ， 他 们 只 是 负责 根据 各 种 配置 文件 ( make *.config ) 生成 不 同 目标 内 核 的， 
为 之 前 我 就 说 了 这 一 部 分 我 们 只 讨论 构建 内 核 的 通用 途径 。 


目标 all: 是 在 命令 行 如 果 不 指定 具体 目标 时 默认 使 用 的 目标 。 你 可 以 看 到 这 里 包含 了 架构 
相关 的 Makefile (在 这 里 就 指 的 是 arch/x86/Makefile ) 。 从 这 一 时 刻 起 ， 我 们 会 从 这 个 
Makefile 继续 进行 下 去 。 如 我 们 所 见 ， 目 标 all 依赖 于 根 Makefile 后 面 声明 的 vmlinux 


vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps) FORCE 


vmlinux Æ linux 内 核 的 静态 链接 可 执行 文件 格式 。 脚 本 scripts/link-vmlinux.sh 把 不 同 的 编 
译 好 的 子 模块 链接 到 一 起 形成 了 vmlinux ° 


第 二 个 目标 是 vmlinux-deps ， 它 的 定义 如 下 : 


vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_INIT) $(KBUILD_VMLINUX_MAIN) 


它 是 由 内 核 代码 下 的 每 个 顶级 目录 的 built-in.o 组 成 的 。 之 后 我 们 还 会 检查 内 核 所 有 的 目 

录 ， Kbuild 会 编译 各 个 目录 下 所 有 的 对 应 $(obj-y) 的 源 文件 。 接 着 调用 $(LD) -r 把 这 

些 文件 合并 到 一 个 puild-in.o 文件 里 。 此 时 我 们 还 没有 vmlinux-deps ， 所 以 目标 vmlinux 
现在 还 不 会 被 构建 。 对 我 而 言 vmlinux-deps 包含 下 面 的 文件 : 


arch/x86/kernel/vmlinux.lds arch/x86/kernel/head_64.0 
arch/x86/kernel/head64.o0 arch/x86/kernel/head.o 


init/built-in.o usr/built-in.o 
arch/x86/built-in.o kernel/built-in.o 
mm/built-in.o fs/built-in.o 
ipc/built-in.o security/built-in.o 
crypto/built-in.o block/built-in.o 
lib/lib.a arch/x86/lib/lib.a 
lib/built-in.o arch/x86/1lib/built-in.o 
drivers/built-in.o sound/built-in.o 
firmware/built-in.o arch/x86/pci/built-in.o 


arch/x86/power/built-in.o arch/x86/video/built-in.o 
net/built-in.o 


下 一 个 可 以 被 执行 的 目标 如 下 : 


$(sort $(vmlinux-deps)): $(vmlinux-dirs) ; 
$(vmlinux-dirs): prepare scripts 
$(Q)$(MAKE) $(build)=$@ 


Je 


就 像 我 们 看 到 的 ， vmlinux-dir 依赖 于 两 部 分 : prepare 和 scripts 。 第 一 个 prepare Æ 
义 在 内 核 的 根 makefile 中 ， 准 备 工作 分 成 三 个 阶段 : 


prepare: prepared 
prepareO: archprepare FORCE 
$(Q)$(MAKE) $(build)=. 
archprepare: archheaders archscripts preparei scripts_basic 


prepare1: prepare2 $(version_h) include/generated/utsrelease.h \ 
include/config/auto. conf 
$(cmd_crmodverdir ) 
prepare2: prepare3 outputmakefile asm-generic 


Abe 


第 一 个 prepare0 展开 到 archprepare ? 后 者 又 展开 到 archheader 和 archscripts  ， 这 两 
个 变量 定义 在 x86_64 相关 的 Makefile 。 让 我 们 看 看 这 个 文件 。 x86_64 特定 的 Makefile 从 
变量 定义 开始 ， 这 些 变量 都 是 和 特定 架构 的 配置 文件 (defconfig， 等 等 ) 有 关联 。 在 定义 了 编 
译 16-bit 代码 的 编译 选项 之 后 ， 根 据 变量 BITS 的 值 ， 如果 是 32 ， 汇 编 代 码 、 链 接 器 、 以 
及 其 它 很 多 东西 (全 部 的 定义 都 可 以 在 arch/x86/Makefile 找 到 ) 对 应 的 参数 就 是 i386 ， 而 


64 就 对 应 的 是 x86 84 。 


第 一 个 目标 是 Makefile 生成 的 系统 调用 列表 (syscall table) 中 的 archheaders 


archheaders: 
$(Q)$(MAKE) $(build)=arch/x86/entry/syscalls all 


第 二 个 目标 是 Makefile 里 的 archscripts 


archscripts: scripts_basic 
$(Q)$(MAKE) $(build)=arch/x86/tools relocs 


我 们 可 以 看 到 archscripts 是 依赖 于 根 Makefile 里 的 scripts_basic ° 首先 我 们 可 以 看 出 
scripts_basic 是 按照 scripts/basic 的 Makefile 执行 make 的 : 


scripts_basic: 
$(Q)$(MAKE) $(build)=scripts/basic 


scripts/basic/Makefile 包含 了 编译 两 个 主机 程序 fixdep 和 bin2 的 目标 : 


hostprogs-y := fixdep 
hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c 
always := $(hostprogs-y) 


$(addprefix $(obj)/,$(filter-out fixdep,$(always))): $(obj)/fixdep 


第 一 个 工具 是 fixdep : 用 来 优化 gcc 生成 的 依赖 列表 ， 然 后 在 重新 编译 源 文 件 的 时 候 告 诉 
make 。 第 二 个 工具 是 binc ， 它 依赖 于 内 核 配 置 选项 CONFIG_BUILD_BIN2C ， 并 且 它 是 一 
个 用 来 将 标准 输入 接口 (LCTT 译注 : BP stdin) 收 到 的 二 进 制 流 通过 标准 输出 接口 ( 即 : 
stdout) 转换 成 C 头 文件 的 非常 小 的 C 程序 。 你 可 能 注意 到 这 里 有 些 奇 怪 的 标志 ， 如 
hostprogs-y 等 。 这 个 标志 用 于 所 有 的 kbuild 文件 ， 更 多 的 信息 你 可 以 从 documentation 
获得 。 在 我 们 这 里 ， hostprogs-y 告诉 kbuild 这 里 有 个 名 为 fixed 的 程序 ， 这 个 程序 会 
通过 和 Makefile 相同 目录 的 fixdep.c 编译 而 来 。 


执行 make 之 后 ， 终 端的 第 一 个 输出 就 是 kbuild 的 结果 : 


$ make 
HOSTCC scripts/basic/fixdep 


当 目 标 script_basic 被 执行 ， 目 标 archscripts 就 会 make arch/x86/tools F 4 Makefile 


和 目标 relocs 


$(Q)$(MAKE) $(build)=arch/x86/tools relocs 


包含 了 重 定 位 的 信息 的 代码 relocs_32.c 和 relocs_64.c 将 会 被 编译 ， 这 可 以 在 make 的 
输出 中 看 到 : 


HOSTCC arch/x86/tools/relocs_32.0 
HOSTCC arch/x86/tools/relocs_64.0 
HOSTCC arch/x86/tools/relocs_common.o 
HOSTLD arch/x86/tools/relocs 


在 编译 完 relocs.c 之 后 会 检查 version.h 


$(version_h): $(srctree)/Makefile FORCE 
$(call filechk, version.h) 
$(Q)rm -f $(old_version_h) 


我 们 可 以 在 输出 看 到 它 : 


CHK include/config/kernel.release 


以 及 在 内 核 的 根 Makefile 使 用 arch/x86/include/generated/asm 的 目标 asm-generic 来 构建 
Benes 汇编 头 文件 。 在 目标 asm-generic 之 后 ， archprepare 就 完成 了 ， 所 以 目标 
prepareo 会 接着 被 执行 ， 如 我 上 面 所 写 : 


prepare0: archprepare FORCE 
$(Q)$(MAKE) $(build)=. 


注意 build ， 它 是 定义 在 文件 scripts/Kbuild.include ， 内 容 是 这 样 的 : 


build := -f $(srctree)/scripts/Makefile.build obj 


或 者 在 我 们 的 例子 中 ， 它 就 是 当前 源码 目录 路 径 - 


$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.build obj=. 


脚本 scripts/Makefile.build 通过 参数 obj 给 定 的 目录 找到 Kbuild 文件 ， 然 后 引入 Kbuild 
文件 : 


include $(kbuild-file) 


并 根据 这 个 构建 目标 。 我 们 这 里 | 包含 了 生成 kernel/bounds.s 和 arch/x86/kernel/asm- 
offsets.s 49 Kbuild 文件 。 在 此 之 后 ， 目 标 prepare 就 完成 了 它 的 工作 。 vmlinux-dirs 也 
依赖 于 第 二 个 目标 scripts ? 它 会 编译 接 下 来 的 几 个 程序 : filealias ， mk_elfconfig ° 
modpost 等 等 。 之 后 ， scripts/host-programs 就 可 以 开始 编译 我 们 的 目标 vmlinux-dirs 

了 。 


首先 ， 我 们 先 来 理解 一 下 vmlinux-dirs 都 包含 了 那些 东西 。 在 我 们 的 例子 中 它 包 含 了 下 列 内 
核 目 录 的 路 径 : 


init usr arch/x86 kernel mm fs ipc security crypto block 
drivers sound firmware arch/x86/pci arch/x86/power 
arch/x86/video net lib arch/x86/1ib 


我 们 可 以 在 内 核 的 根 Makefile 里 找到 vmlinux-dirs 的 定义 : 


vmlinux-dirs := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \ 
$(core-y) $(core-m) $(drivers-y) $(drivers-m) \ 
$(net-y) $(net-m) $(libs-y) $(1libs-m))) 


init-y := init/ 

drivers-y := drivers/ sound/ firmware/ 
net-y := net/ 

libs-y := lib/ 


RERED AA patsubst 和 filter 去 掉 了 每 个 目录 路 径 里 的 符号 / ， 并 且 把 结果 放 
到 vmlinux-dirs 里 。 所 以 我 们 就 有 了 vmlinux-dirs 里 的 目录 列表 ， 以 及 下 面 的 代码 : 


$(vmlinux-dirs): prepare scripts 
$(Q)$(MAKE) $(build)=$@ 


符号 $@ 在 这 里 代表 了 vmlinux-dirs ? 这 就 表明 程序 会 递归 遍历 从 vmlinux-dirs 以 及 它 
内 部 的 全 部 目录 (依赖 于 配置 ) ， 并 且 在 对 应 的 目录 下 执行 make 命令 。 我 们 可 以 在 输出 看 
到 结果 : 


cc init/main.o 

CHK include/generated/compile.h 

cc init/version.o 

cc init/do_mounts.o 

cc arch/x86/crypto/glue_helper.o 

AS arch/x86/crypto/aes -x86_64-asm_64.0 
cc arch/x86/crypto/aes_glue.o 

AS arch/x86/entry/entry_64.0 

AS arch/x86/entry/thunk_64.0 

cc arch/x86/entry/syscall_64.0 


每 个 目录 下 的 源 代码 将 会 被 编译 并 且 链 接 到 puilt-io.o Æ: 


$ find . -name built-in.o 
./arch/x86/crypto/built-in.o 
./arch/x86/crypto/sha-mb/built-in.o 
./arch/x86/net/built -in.o 
./init/built-in.o 

./usr/built-in.o 


好 了 ， 所 有 的 built-in.o 都 构建 完了 ， 现 在 我 们 回 到 目标 vmlinux 上 。 你 应 该 还 记得 ， 目 
标 vmlinux 是 在 内 核 的 根 Makefile 里 。 在 链接 vmlinux 之 前 ， 系 统 会 构建 samples , 
Documentation 等 等 ， 但 是 如 上 文 所 述 ， 我 不 会 在 本 文 描述 这 些 。 


vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps) FORCE 


+$(call if_changed, link-vmlinux) 


你 可 以 看 到 ， 调 用 脚本 scripts/link-vmlinux.sh 的 主要 目的 是 把 所 有 的 puilt-in.o 链接 成 一 
个 静态 可 执行 文件 ， 和 生成 System.map 。 最 后 我 们 来 看 看 下 面 的 输出 : 


LINK vmlinux 


LD vmlinux.o 

MODPOST vmlinux.o 

GEN .version 

CHK include/generated/compile.h 
UPD include/generated/compile.h 
CC init/version.o 

LD init/built-in.o 

KSYM . tmp_kallsyms1.o 

KSYM . tmp_kallsyms2.0 

LD vmlinux 


SORTEX vmlinux 
SYSMAP System.map 


vmlinux 和 system.map 生成 在 内 核 源 码 树 根 目 录 下 。 


$ ls vmlinux System.map 
System.map vmlinux 


这 就 是 全 部 了 ， vmlinux 构建 好 了 ， 下 一 步 就 是 创建 bzlmage. 


制作 bzlmage 


bzImage 就 是 压缩 了 的 linux 内 核 镜像 。 我 们 可 以 在 构建 了 vmlinux 之 后 通过 执行 make 
bzImage 获得 bzImage 。 同 时 我 们 可 以 仅仅 执行 make 而 不 带 任何 参数 也 可 以 生成 bzImage 
， 因 为 它 是 在 arch/x86/kernel/Makefile 里 预定 义 的 、 默 认 生成 的 镜像 : 


all: bzImage 


让 我 们 看 看 这 个 目标 ， 它 能 帮助 我 们 理解 这 个 镜像 是 怎么 构建 的 。 我 已 经 说 过 了 bzImage 是 
被 定义 在 arch/x86/kernel/Makefile ， 定 义 如 下 : 


bzImage: vmlinux 
$(Q)$(MAKE) $(build)=$(boot) $(KBUILD_IMAGE) 
$(Q)mkdir -p $(objtree)/arch/$(UTS_MACHINE)/boot 
$(Q)1n -fsn ../../x86/boot/bzImage $(objtree)/arch/$(UTS_MACHINE) /boot/$@ 


在 这 里 我 们 可 以 看 到 第 一 次 为 boot 目录 执行 make ， 在 我 们 的 例子 里 是 这 样 的 : 


boot := arch/x86/boot 


现在 的 主要 目标 是 编译 目录 arch/xs6/boot 和 arch/x86/boot/compressed 的 代码 ， 构 建 
setup.bin 和 vmlinux.bin ， 最 后 用 这 两 个 文件 生成 bzImage ° 第 一 个 目 标 是 定义 在 
arch/x86/boot/Makefile 的 $(obj)/setup.elf 


$(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS) FORCE 
$(call if_changed, 1d) 


我 们 已 经 在 目录 arch/xs6/boot 有 了 链接 脚本 setup.ld ， 和 扩展 到 boot 目录 下 全 部 源 代 
码 的 变量 SETUP_0BJS 。 我 们 可 以 看 看 第 一 个 输出 : 


AS arch/x86/boot/bioscall.o 
CC arch/x86/boot/cmdline.o 
AS arch/x86/boot/copy.o 


HOSTCC arch/x86/boot/mkcpustr 
CPUSTR arch/x86/boot/cpustr.h 


CC arch/x86/boot/cpu.o 

cc arch/x86/boot/cpuflags.o 

CC arch/x86/boot/cpucheck.o 

cc arch/x86/boot/early_serial_console.o 
cc arch/x86/boot/edd.o 


下 一 个 源码 文件 是 arch/x86/boot/header.S ， 但 是 我 们 不 能 现在 就 编译 它 ， 因 为 这 个 目标 依赖 
于 下 面 两 个 头 文件 : 


$(obj)/header.o: $(obj)/voffset.h $(obj)/zoffset.h 


第 一 个 头 文件 voffset.h 是 使 用 sed 脚本 生成 的 ， 包 含 用 nm 工具 从 vmlinux 获取 的 两 
个 地 址 : 


#define VO__end 09xffffffff82ab0000 
#define VO_ text OxffffffFfF81000000 


这 两 个 地 址 是 内 核 的 起 始 和 结束 地 址 。 第 二 个 头 文件 zoffset.h 在 
arch/x86/boot/compressed/Makefile 可 以 看 出 是 依赖 于 目标 vmlinux 的 : 


$(obj)/zoffset.h: $(obj)/compressed/vmlinux FORCE 
$(call if_changed, zoffset) 





目标 $(obj )/compressed/vmlinux 依赖 于 vmlinux-objs-y 说 明 需要 编译 目录 
arch/x86/boot/compressed 下 的 源 代码 ， 然 后 生成 vmlinux.bin ` vmlinux.bin.bz2 ， 和 编 
译 工具 mkpiggy 。 我 们 可 以 在 下 面 的 输出 看 出 来 : 


LDS arch/x86/boot/compressed/vmlinux. lds 
AS arch/x86/boot/compressed/head_64.0 
cc arch/x86/boot/compressed/misc.o 

CC arch/x86/boot/compressed/string.o 

cc arch/x86/boot/compressed/cmdline.o 


OBJCOPY arch/x86/boot/compressed/vmlinux. bin 
BZIP2 arch/x86/boot/compressed/vmlinux.bin.bz2 
HOSTCC arch/x86/boot/compressed/mkpiggy 


vmlinux.bin 是 去 掉 了 调试 信 息 和 aa vmlinux 二 进 制 文件 ， 加 上 了 占用 了 u32 

(LCTT 译注 : 即 4-Byte) 的 长 度 信 息 的 vmlinux.bin.all 压缩 后 就 是 vmlinux.bin.bz2 。 
其 中 vmlinux.bin.all 包含 了 vmlinux.bin 和 vmlinux.relocs (LCTT 译 注 : vmlinux 的 重 
定位 信息 ) > 其 中 vmlinux.relocs 是 vmlinux 经 过 程序 relocs 处 理 之 后 的 vmlinux 镜 
像 ( 见 上 文 所 述 ) 。 我 们 现在 已 经 获取 到 了 这 些 文件 ， 汇 编 文 件 piggy.s 将 会 被 mkpiggy 
生成 、 然 后 编译 : 


MKPIGGY arch/x86/boot/compressed/piggy.S 
AS arch/x86/boot/compressed/piggy.o 


这 个 汇编 文件 会 包含 经 过 计算 得 来 的 、 压 缩 内 核 的 偏 移 信息 。 处 理 完 这 个 汇编 文件 ， 我 们 就 
可 以 看 到 zoffset 生成 了 : 


ZOFFSET arch/x86/boot/zoffset.h 


现在 zoffset.h 和 voffset.h 已 经 生成 了 ，arch/x86/boot 里 的 源 文件 可 以 继续 编译 : 


AS arch/x86/boot/header .0 

cc arch/x86/boot/main.o 

CC arch/x86/boot/mca.o 

cc arch/x86/boot/memory.o 

CC arch/x86/boot/pm.o 

AS arch/x86/boot/pmjump.o 

cc arch/x86/boot/printf.o 

cc arch/x86/boot/regs.o 

cc arch/x86/boot/string.o 

cc arch/x86/boot/tty.o 

cc arch/x86/boot/video.o 

cc arch/x86/boot/video-mode.o 
cc arch/x86/boot/video-vga.o 
cc arch/x86/boot/video-vesa.o 
cc arch/x86/boot/video-bios.o 


所 有 的 源 代码 会 被 编译 ， 他 们 最 终 会 被 链接 到 setup.elf 


LD arch/x86/boot/setup.elf 


ld -m elf_x86_64 -T arch/x86/boot/setup.ld arch/x86/boot/a20.0 arch/x86/boot/bioscal 
l.o arch/x86/boot/cmdline.o arch/x86/boot/copy.o arch/x86/boot/cpu.o arch/x86/boot/cpu 
flags.o arch/x86/boot/cpucheck.o arch/x86/boot/early_serial_console.o arch/x86/boot/ed 
d.o arch/x86/boot/header.o arch/x86/boot/main.o arch/x86/boot/mca.o arch/x86/boot/memo 
ry.o arch/x86/boot/pm.o arch/x86/boot/pmjump.o arch/x86/boot/printf.o arch/x86/boot/re 
gs.0 arch/x86/boot/string.o arch/x86/boot/tty.o arch/x86/boot/video.o arch/x86/boot/vi 
deo-mode.o arch/x86/boot/version.o arch/x86/boot/video-vga.o arch/x86/boot/video-vesa. 
o arch/x86/boot/video-bios.o -o arch/x86/boot/setup. elf 


最 后 的 两 件 事 是 创建 包含 目录 arch/xse/boot/* 下 的 编译 过 的 代码 的 setup.bin 


objcopy -0 binary arch/x86/boot/setup.elf arch/x86/boot/setup.bin 


以 及 从 vmlinux 生成 vmlinux.bin 


objcopy -0 binary -R ,note -R .comment -S arch/x86/boot/compressed/vmlinux arch/x86/b 
oot/vmlinux.bin 


最 最 后 ， 我 们 编译 主机 程序 arch/x86/boot/tools/build.c ， 它 将 会 用 来 把 setup.bin 和 
vmlinux.bin 打包 成 bzImage 


arch/x86/boot/tools/build arch/x86/boot/setup.bin arch/x86/boot/vmlinux.bin arch/x86/b 
oot/zoffset.h arch/x86/boot/bzImage 


实际 上 pzImage 就 是 把 setup.bin 和 vmlinux.bin 连接 到 一 起 。 最 终 我 们 会 看 到 输出 结 
果 ， 就 和 那些 用 源码 编译 过 内 核 的 同行 的 结果 一 样 : 


Setup is 16268 bytes (padded to 16384 bytes). 
System is 4704 kB 

CRC 94a88f9a 

Kernel: arch/x86/boot/bzImage is ready (#5) 


后 生成 bzImage ° 44038 > linux 内 核 的 Makefile 和 构建 linux 的 过 程 第 一 眼看 起 来 可 能 比 
较 迷 惑 ， 但 是 这 并 不 是 很 难 。 希 望 本文 可 以 帮助 你 理解 构建 linux 内 核 的 整个 流程 。 


注 : 本 文 由 LCTT 原创 翻译 ，Linux 中 国 荣誉 推出 


链接 


e GNU make util 

e Linux kernel top Makefile 
e cross-compilation 
e Ctags 

e sparse 

e bzlmage 

e uname 

e shell 

e Kbuild 

e binutils 

e gcc 

e Documentation 
e System.map 

e Relocation 


在 写 linux-insides 一 书 的 过 程 中 ， 我 收 到 了 很 多 邮件 询问 关于 链接 器 和 链接 器 脚本 的 问题 。 
所 以 我 决定 写 这 篇 文章 来 介绍 链接 器 和 目标 文件 的 链接 方面 的 知识 。 


如 果 我 们 打开 维基 百科 的 链接 器 ， 我 们 将 会 看 到 如 下 定义 : 


在 计算 机 科学 中 ， 链 接 器 (英文 : Linker) ， 是 一 个 计算 机 程序 ， 它 将 一 个 或 多 个 由 编译 
器 生成 的 目标 文件 链接 为 一 个 单独 的 可 执行 文件 ， 库 文件 或 者 另外 一 个 目标 文件 


如 果 你 曾经 用 C 写 过 至 少 一 个 程序 ， 那 你 就 已 经 见 过 以 *.o 扩展 名 结尾 的 文件 了 。 这 些 文 
件 是 目标 文件 。 目 标 文件 是 一 块 块 的 机 器 码 和 数据 ， 其 数据 包含 了 引用 其 他 目标 文件 或 库 的 
数据 和 函数 的 占 位 符 地 址 ， 也 包括 其 自身 的 函数 和 数据 列表 。 链 接 器 的 主要 目的 就 是 收集 /处 
理 每 一 个 目标 文件 的 代码 和 数据 ， 将 它们 转 成 最 终 的 可 执行 文件 或 者 库 。 在 这 篇 文章 里 ， 我 
们 会 试 着 研究 这 个 流程 的 各 个 方面 。 开 始 吧 。 


链接 流程 
让 我 们 按 以 下 结构 创建 一 个 项 目 : 


*-linkers 
*--main.c 
*--lib.c 
*--lib.h 


我 们 的 main.c 源 文件 包含 了 : 


#include <stdio.h> 
#include "lib.h" 
int main(int argc, char **argv) { 


printf("factorial of 5 is: %d\n", factorial(5)); 
return 0; 


lib.c 文件 包含 了 : 


int factorial(int base) { 
i Smee = 


if (base == 0) { 


return T: 

} 

while (i <= base) { 
res *= i; 
i++; 


了 


return res; 


lib.h 文件 包含 了 : 


#ifndef LIB_H 
#define LIB_H 


int factorial(int base); 


#endif 


现在 让 我 们 用 以 下 命令 单独 编译 main.c 源码 : 


$ gcc -c main.c 


如 果 我 们 用 nm 工具 查看 输出 的 目标 文件 ， 我 们 将 会 看 到 如 下 输出 : 


$ nm -A main.o 


main.o: U factorial 
main.0:0000000000000000 T main 
main.o: U printf 


nm 工具 让 我 们 能 够 看 到 给 定 目 标 文件 的 符号 表 列 表 。 其 包含 了 三 列 : 第 一 列 是 该 目标 文件 
的 名 称 和 解析 得 到 的 符号 地 址 。 第 二 列 包 含 了 一 个 表示 该 符号 状态 的 字符 。 这 里 U 表示 未 
定义 ， T 表示 该 符号 被 置 于 tet 段 。 在 这 里 ， m 工具 向 我 们 展示 了 mainc 文件 里 


e factorial -在 lib.c 文件 中 定义 的 阶乘 防 数 。 因 为 我 们 只 编译 了 main.c ， 所 以 其 不 
知道 任何 有 关 lib.c 文件 的 事 ; 

© main - £ HR: 

e printf - RA glibc 库 的 函数 。 main.c 同样 不 知道 任何 与 其 相关 的 事 。 


目前 我 们 可 以 从 nm 的 输出 中 了 解 哪些 事情 呢 ? main.o 目标 文件 包含 了 在 地 址 
0000000000000000 处 的 本 地 变量 main (在 被 链接 后 其 将 会 被 赋予 正确 的 地 址 ) ， 以 及 两 个 
无 法 解析 的 符号 。 我 们 可 以 从 main.o 的 反 汇 编 输出 中 了 解 这 些 信息 : 

$ objdump -S main.o 


main.o: file format elf64-x86-64 
Disassembly of section .text: 


0000000000000000 <main>: 


O: 55 push %rbp 

1 48 89 e5 mov %rsp,%rbp 

4: 48 83 ec 10 sub $0x10,%rsp 

8: 89 7d fc mov %edi, -Ox4(%rbp) 
b 48 89 75 fO mov %rsi, -Ox10(%rbp) 
rhs bf 05 00 00 00 mov $0x5,%edi 

14: e8 00 00 00 00 callq 19 <main+0x19> 
19: 89 c6 mov %eax,%esi 

1b: bf 00 00 00 00 mov $0x0, %edi 

20: b8 00 00 00 00 mov $0x0, %eax 

25: e8 00 00 00 00 callq 2a <main+0x2a> 
2a: b8 00 00 00 00 mov $0x0, %eax 

2f: c9 leaveq 

30: c3 retq 


这 里 我 们 只 关注 两 个 callq 操作 。 这 两 个 calla 操作 包含 了 链接 器 存根 ， 或 者 函数 的 名 称 
和 其 相对 当前 的 下 一 条 指令 的 偏 移 。 这 些 存 根 将 会 被 更 新 到 函 数 的 丨 实地 址 。 我 们 可 以 在 下 
面 的 objdump 输出 看 到 这 些 函 数 的 名 字 : 


$ objdump -S -r main.o 


14: e8 00 00 00 00 callq 19 <main+0x19> 


15: R_X86_64_PC32 factorial-0x4 
19: 89 c6 mov %eax,%esi 
25: e8 00 00 00 00 callq 2a <main+0x2a> 
26: R_X86_64_PC32 printf-0x4 
2a: b8 00 00 00 00 mov $0x0, %eax 


objdump 工具 中 的 -r 或 --reloc 选项 会 打印 文件 的 重 定位 条 目 。 现 在 让 我 们 更 加 深入 


重 定位 流程 。 





\s 


重 


Py 
rey 


重 定位 是 连接 符号 引用 和 符号 定义 的 流程 。 让 我 们 看 看 前 一 段 objdump 的 输出 : 


14: e8 00 00 00 00 callq 19 <main+0x19> 
15: R_X86_64_PC32 factorial-0x4 
19: 89 c6 mov %eax,%esi 


注意 第 一 行 的 es 00 00 00 00 ° es 是 call 的 操作 码 ， 这 一 行 的 剩余 部 分 是 一 个 相对 偏 
移 。 所 以 es oo 00 00 包含 了 一 个 单字 节操 作 码 ， 跟 着 一 个 四 字 节 地 址 。 注 意 00 00 00 00 
是 4 个 字 节 。 为 什么 只 有 4 字 节 而 不 是 x86_64 64 位 机 器 上 的 8 字 节 地 址 ?了 其实 我 们 用 了 
-mcmodel=small 选项 来 编译 main.c |! 从 gcc 的 指南 上 看 : 


-mcmodel=small 
为 小 代码 模型 生成 代码 ; 目标 程序 及 其 符号 必须 被 链接 到 低 于 2GB 的 地 址 空间 。 指 针 是 64 位 的 。 程 序 可 以 被 动态 


或 静态 的 链接 。 这 是 默认 的 代码 模型 。 


当然 ， 我 们 在 编译 时 并 没有 将 这 一 选项 传 给 gcc ， 但 是 这 是 默认 的 。 从 上 面 摘录 的 gee 指 
南 我 们 知道 ， 我 们 的 程序 会 被 链接 到 低 于 2 GB 的 地 址 空间 。 因 此 4 字 节 已 经 足够 。 所 以 我 
MAT call 指令 和 一 个 未 知 的 地 址 。 当 我 们 编译 main.c 以 及 它 的 依赖 形成 一 个 可 执行 文 
件 时 ， 关 注 阶乘 函数 的 调用 ， 我 们 看 到 : 

$ gcc main.c lib.c -o factorial | objdump -S factorial | grep factorial 

factorial: file format elf64-x86-64 


0000000000400506 <main>: 
40051a: e8 18 00 00 00 callq 400537 <factorial> 


0000000000400537 <factorial>: 


400550: 75 07 jne 400559 <factorial+0x22> 
400557: eb 1b jmp 400574 <factorial+0x3d> 
400559: eb Oe jmp 400569 <factorial+0x32> 
40056f : 7e ea jle 40055b <factorial+0x24> 


在 前 面 的 输出 中 我 们 可 以 看 到 ， main 函数 的 地 址 是 oxooooooooo40506 。 为 什么 它 不 是 从 
oxo 开始 的 呢 ? 你 可 能 已 经 知道 标准 C 程序 是 使 用 glibc 的 C 标准 库 链接 的 (假设 参数 
-nostdlib 没有 被 传 给 gcc ) 。 编 译 后 的 程序 代码 包含 了 用 于 在 程序 启动 时 初始 化 程序 中 

数据 的 构造 函数 。 这 些 函 数 需要 在 程序 启动 前 被 调用 ， 或 者 说 在 main 函数 之 前 被 调用 。 为 
了 让 初始 化 和 终止 函数 起 作用 ， 编 译 器 必须 在 汇编 代码 中 输出 一 些 让 这 些 函 数 在 正确 时 间 被 

调用 的 代码 。 执 行 这 个 程序 将 会 启动 位 于 特殊 的 init 段 的 代码 。 我 们 可 以 从 以 下 的 

objdump 输出 中 看 出 : 


objdump -S factorial | less 


factorial: file format elf64-x86-64 


Disassembly of section .init: 


00000000004003a8 <_init>: 


4003a8: 48 83 ec 08 sub $0x8,%rsp 
4003ac: 48 8b 05 a5 05 20 00 mov 0x2005a5(%rip),%rax # 600958 <_D 
YNAMIC+0x1d0> 


注意 其 开始 于 相对 glibc 代码 偏 移 oxoooo0000004003a8 的 地 址 。 我 们 也 可 以 运行 readelf 
> 在 ELF 输出 中 检查 : 


$ readelf -d factorial | grep \(INIT\) 
0x000000000000000c (INIT) 0x4003a8 


所 以 ， main Axha Æ oo00000000400506 ， 为 相对 于 init 段 的 偏 移 地 址 。 我 们 可 以 
从 输出 中 看 出 ， factorial 函数 的 地 址 是 oxoooo000000400537 ， 并 且 现 在 调用 factorial 
函数 的 二 进 制 代码 是 e8 18 00 00 00 。 我 们 已 经 知道 es 是 call 指令 的 操作 码 ， 接 下 来 
的 18 00 00 00 (注意 x86_64 中 地 址 是 小 头 存储 的 ， 所 以 是 oo o0 gg 18 ) 是 从 callg 
到 factorial 函数 的 偏 移 。 


>>> hex(0x40051a + 0x18 + 0x5) == hex(0x400537) 
True 


所 以 我 们 把 oxis 和 oxs 加 到 call 指令 的 地 址 上 。 偏 移 是 从 接 下 来 一 条 指令 开始 算 起 
的 。 我 们 的 调用 指令 是 5 字 节 长 ( es 18 00 o0 o0 ) 并 且 oxig 是 从 factorial 函数 之 后 
的 调用 算 起 的 偏 移 。 编 译 器 一 般 按 程序 地 址 从 零 开始 创建 目标 文件 。 但 是 如 果 程 序 由 多 个 目 
标 文 件 生 成 ， 这 些 地 址 会 重重。 


我 们 在 这 一 段 看 到 的 是 重 定位 流程 。 这 个 流程 为 程序 中 各 个 部 分 赋予 加 载 地 址 ， 调 整 程序 中 
的 代码 和 数据 以 反映 出 赋值 的 地 址 。 


好 了 ， 现 在 我 们 知道 了 一 点 关于 链接 器 和 重 定位 的 知识 ， 是 时 候 通 过 链接 我 们 的 目标 文件 来 
来 学 习 更 多 关于 链接 器 的 知识 了 。 


GNU 4444 4 


如 标题 所 说 ， 在 这 篇 文章 中 ， 我 将 会 使 用 GNU 链接 器 或 者 说 1d 。 当 然 我 们 可 以 使 用 gcc 
来 链接 我 们 的 factorial MA : 


$ gcc main.c lib.o -o factorial 


在 这 之 后 ， 作 为 结果 我 们 将 会 得 到 可 执行 文件 一 factorial 


./factorial 
factorial of 5 is: 120 


但 是 gcc 不 会 链接 目标 文件 。 取 而 代 之 ， 其 会 使 用 GUN id 链接 器 的 包装 





collect2 ° 


~$ /usr/lib/gcc/x86_64-linux-gnu/4.9/collect2 --version 
collect2 version 4.9.3 

/usr/bin/ld --version 

GNU ld (GNU Binutils for Debian) 2.25 


好 ， 我 们 可 以 使 用 gcc 并 且 其 会 为 我 们 的 程序 生成 可 执行 文件 。 但 是 让 我 们 看 看 如 何 使 用 
GUN ld 实现 相同 的 目的 。 首 先 ， 让 我 们 尝试 用 如 下 样 例 链接 这 些 目 标 文件 : 


ld main.o lib.o -o factorial 


Wik 


试 一 下 ， 你 将 会 得 到 如 下 错误 : 


$ ld main.o lib.o -o factorial 

ld: warning: cannot find entry symbol _start; defaulting to 00000000004000b0 
main.o: In function `main': 

main.c:(.text+0x26): undefined reference to `printf' 


这 里 我 们 可 以 看 到 两 个 问题 : 


o 链接 器 无 法 找到 _start 符号 ; 
o 链接 器 对 printf 一 无 所 知 。 


首先 ， 让 我 们 尝试 理解 好 像 是 我 们 程序 运行 所 需要 的 start 入 口 符 号 是 什么 。 当 我 开始 学 
习 编 程 时 ， 我 知道 了 main 函数 是 程序 的 入 口 点 。 我 认为 你 们 也 是 如 此 认为 的 :) 但 实际 上 这 
不 是 入 口 点 ， start Fee _start 符号 被 crt1.6 所 定义 。 我 们 可 以 用 如 下 指令 发 现 


pn 


Ers 


$ objdump -S /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.0 


/usr/1ib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o: file format el 
f64-x86-64 


Disassembly of section .text: 


0000000000000000 <_start>: 
O: 31 ed xor %ebp, %ebp 
2: 49 89 d1 mov %rdx,%r9 


我 们 将 该 目标 文件 作为 第 一 个 参数 传递 给 1d 指令 (如 上 所 示 ) 。 现 在 让 我 们 尝试 链接 它 ， 
会 得 到 如 下 结果 : 


ld /usr/1lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o \ 
main.o lib.o -o factorial 


/usr/1lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o0: In function ~_star 
tie 

/tmp/buildd/glibc-2.19/csu/../sysdeps/x86_64/start.S:115: undefined reference to ~_ li 
bc_csu_fini' 

/tmp/buildd/glibc-2.19/csu/../sysdeps/x86_64/start.S:116: undefined reference to ~_ li 
bc_csu_init' 

/tmp/buildd/glibc-2.19/csu/../sysdeps/x86_64/start.S:122: undefined reference to ~_ li 
bc_start_main' 

main.o: In function `main': 

main.c:(.text+0x26): undefined reference to `printf' 


不 幸 的 是 ， 我 们 甚至 会 看 到 更 多 报错 。 我 们 可 以 在 这 里 看 到 关于 未 定义 printf 的 旧 错 误 以 
及 另外 三 个 未 定义 的 引用 : 


© 1ibc csu fini 
© __libc_csu_init 
© __libc_start_main 


_start 符号 被 定义 在 glibc 源 文件 的 汇编 文件 sysdeps/x86 64/start.S 中 。 我 们 可 以 在 那 
里 找到 如 下 汇编 代码 : 


mov $__libc_csu_fini, %R8_LP 
mov $ libc csu_init, %RCX_LP 


call _ libc start _ main 


这 里 我 们 传递 了 init 和 fini 段 的 入 口 点 地 址 ， 它 们 包含 了 程序 开始 和 结束 时 被 执行 的 
代码 。 并 且 在 结尾 我 们 看 到 对 我 们 程序 的 main 函数 的 调用 。 这 三 个 符号 被 定义 在 源 文件 
csu/elf-init.c 中 。 如 下 两 个 目标 文件 : 


e crtn.o ; 


© crti.o. 
定义 了 .init 和 fini 段 的 开端 和 尾声 (分 别 为 符号 init 和 _fini ) ° 


crtn.o 目标 文件 包含 了 init 和 .fini 这 些 段 : 


$ objdump -S /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o 


0000000000000000 <.init>: 
O: 48 83 c4 08 add $0x8,%rsp 
4: c3 retq 


Disassembly of section .fini: 


0000000000000000 <.fini>: 
0: 48 83 c4 08 add $0x8,%rsp 
4: c3 retq 


E crti.o 目标 文件 包含 了 符号 init 和 fini 。 让 我 们 再 次 尝试 链接 这 两 个 目标 文件 : 


$ ld \ 

/usr/1lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o \ 
/usr/1ib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o \ 
/usr/1lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o main.o lib.o \ 
-o factorial 


当然 ， 我 们 会 得 到 相同 的 错误 。 现 在 我 们 需要 把 -lc 选项 传递 给 1d 。 这 个 选项 将 会 在 环 
境 变 量 $LD_LIBRARY_PATH 指定 的 目录 中 搜索 标准 库 。 让 我 们 再 次 尝试 用 -lc 选项 链接 : 


$ ld \ 

/usr/1ib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1i.o \ 
/usr/1ib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o \ 
/usr/1ib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o main.o lib.o -lc \ 
-o factorial 


BI ANT RAE TT -ATRIL 12 ete RAM ARABTEC > RNS SEN : 


$ ./factorial 
bash: ./factorial: No such file or directory 


这 里 除了 什么 问题 ?让 我 们 用 readelf 工具 看 看 这 个 可 执行 文件 : 


$ readelf -1 factorial 


Elf file type is EXEC (Executable file) 


Entry point 0x4003c0 


There are 7 program headers, starting at offset 64 


Program Headers: 


Type offset VirtAddr PhysAddr 
FileSiz MemSiz Flags Align 

PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040 
0x0000000000000188 0x0000000000000188 RE 8 

INTERP 0x00000000000001c8 0x00000000004001c8 0x00000000004001c8 
0x000000000000001c 0x000000000000001c R ak 


[Requesting program interpreter: /11b64/ld-linux-x86-64.s0.2] 


LOAD 0x0000000000000000 Ox0000000000400000 0x0000000000400000 
0x0000000000000610 Ox0000000000000610 RE 200000 

LOAD 0x0000000000000610 O0x0000000000600610 0x0000000000600610 
0x00000000000001cc 0x00000000000001cc RW 200000 

DYNAMIC 0x0000000000000610 0x0000000000600610 0x0000000000600610 
0x0000000000000190 0x0000000000000190 RW 8 

NOTE 0x00000000000001e4 0x00000000004001e4 0x00000000004001e4 
0x0000000000000020 0x0000000000000020 R 4 

GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 
0x0000000000000000 0x0000000000000000 RW 10 

Section to Segment mapping: 

Segment Sections... 

00 

01 .interp 

02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel 

a.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame 

03 .dynamic .got .got.plt .data 

04 . dynamic 

05 .note.ABI-tag 

06 


注意 这 奇怪 的 一 行 : 


INTERP 0x00000000000001c8 Ox00000000004001c8 0x00000000004001c8 


Ox000000000000001c 0x000000000000001c R ili 
[Requesting program interpreter: /11b64/ld-linux-x86-64.so0.2] 


elf 文件 的 .Interp 段 保 存 了 一 个 程序 解释 器 的 路 径 名 或 者 说 .interp 段 就 包含 了 一 1 
动态 链接 器 名 字 的 ascii 字符 串 。 动 态 链接 器 是 Linux 的 一 部 分 ， 其 通过 将 库 的 内 容 从 磁盘 
复制 到 内 存 中 以 加 载 和 链接 一 个 可 执行 文件 被 执行 所 需要 的 动态 链接 库 。 我 们 可 以 从 

readelf 命令 的 输出 中 看 到 ， 针 对 x86 64 架构 ， 其 被 放 在 /1ib64/1d-linux-x86-64.s0.2 ° 
现在 让 我 们 把 1d-linux-x86-64.so.2 的 路 径 和 -dynamic-linker 选项 一 起 传递 给 1d W 
用 ， 然 后 会 看 到 如 下 结果 : 


$ gcc -c main.c lib.c 


$ ld \ 

/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o \ 
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../xX86_64-linux-gnu/crti.o \ 
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../xX86_64-linux-gnu/crtn.o main.o lib.o \ 
-dynamic-linker /1ib64/ld-linux-x86-64.so.2 \ 

-lc -o factorial 


现在 我 们 可 以 像 普 通 可 执行 文件 一 样 执行 


$ ./factorial 


factorial of 5 is: 120 


RAT ! 在 第 一 行 ， 我 们 把 源 文件 main.c 和 lib.c 编译 成 目标 文件 。 执 行 gcc 之 后 我 们 
将 会 获得 main.o 和 lib.o 


$ file lib.o main.o 
lib.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped 
main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped 


在 这 之 后 ， 我 们 用 所 需 的 系统 目标 文件 和 库 连 链接 我 们 的 程序 。 我 们 刚 看 了 一 个 简单 的 关于 

如 何 用 gcc 编译 器 和 GNU ld 链接 器 编译 和 链接 一 个 C 程序 的 样 例 。 在 这 个 样 例 中 ， 我 们 

使 用 了 一 些 Gnu linker 的 命令 行 选项 ， 但 是 除了 -0 、 -dynamic-linker 等 ， 它 还 支持 其 他 
很 多 选项 。 此 外 ，GNU ld 还 拥有 其 自己 的 语言 来 控制 链接 过 程 。 在 接 下 来 的 两 个 段落 中 我 们 
深入 讨论 。 


实用 的 GNU 链接 器 命令 行 选 项 


正如 我 之 前 所 说 ， 你 也 可 以 从 GNU linker 的 指南 看 到 ， 其 拥有 大 量 的 命令 行 选 项 。 我 们 已 
经 在 这 篇 文章 见 到 一 些 : -o <output> -告诉 1d 将 链接 结果 输出 成 一 个 叫做 output 的 文 
件 ， -1<name> - 通过 文件 名 添加 指定 存档 或 者 目标 文件 ” -dynamic-linker 通过 名 字 指 定 动 
态 链接 器 。 当 然 ， ld 支持 更 多 选项 ， 让 我 们 看 看 其 中 的 一 些 。 


第 一 个 实用 的 选项 是 @file 。 在 这 里 file 指定 了 命令 行 选项 将 读 取 的 文件 名 。 上 比如 我 们 
可 以 创建 一 个 叫做 linker.1ld re EO 令 行 参 数 放 进 去 然后 执 
行 : 


$ ld @linker.1ld 


下 一 个 命令 行 选项 是 -bp 或 --format 。 这 个 命令 行 选项 指定 了 输入 的 目标 文件 的 格式 是 
ELF ，DJGPP/COFF 等 。 针 对 输出 文件 也 有 相同 功能 的 选项 --oformat=output-format ° 


下 一 个 命令 行 选项 是 --defsym 。 该 选项 的 完整 格式 是 --defsym=symbol=expression 。 它 允 
许 在 输 文件 中 创建 包含 了 由 表达 式 给 出 了 绝对 地 址 的 全 局 符号 。 在 下 面 的 例子 中 ， 我 们 会 
发 现 这 个 命令 行 选项 很 实用 : 在 Linux 内 核 源 码 中 关于 ARM 架构 内 核 解压 的 Makefile - 
Was pe ern > 我 们 可 以 找到 如 下 定义 : 


LDFLAGS_vmlinux = --defsym _kernel_bss_size=$(KBSS_SZ) 


正如 我 们 所 知 ， 其 在 输出 文件 中 用 bss 段 的 大 小 定义 了 _kernel_bss size 符号 。 这 个 符号 
年 会 作为 第 一 个 汇编 文件 在 内 核 解 压 阶 段 被 执行 


ldr r5, =_kernel_bss_size 


下 一 个 选项 是 -shared ， 其 允许 我 们 创 ane ma -M 或 者 说 -map <filename> 命令 行 选 项 
会 打印 带 符号 信息 的 链接 映射 内 容 。 在 这 


$ ld -M @linker.1ld 


.text 0x00000000004003c0 0x112 

*(.text.unlikely .text.*_unlikely .text.unlikely.*) 

*(.text.exit .text.exit.*) 

*(.text.startup .text.startup.*) 

*(.text.hot .text.hot.*) 

*(.text .stub .text.* .gnu.linkonce.t.*) 

.text 0x00000000004003c0 Ox2a /usr/lib/gcc/x86_64-linux-gnu/4.9/../../ 
. ./X86_64-linux-gnu/crt1.0 


-text 0x00000000004003ea 0x31 main.o 


0x00000000004003ea main 
.text 0x000000000040041b Ox3f lib.o 
0x000000000040041b factorial 
当然 ， GNU 链接 器 支持 标准 的 命令 行 选项 : --help 和 --version 能 够 打印 1d 的 命令 帮 


助 、 使 用 方法 和 版 本 。 以 上 就 是 所 有 关于 GNU 链接 器 命令 行 选项 的 内 容 。 当 然 这 不 是 1d 工 
有 具 支持 的 所 有 命令 行 选项 。 你 可 以 在 指南 中 找到 1d 工具 的 完整 文档 。 


链接 器 控制 语言 


如 我 之 前 所 说 ， 1d 支持 它 自己 的 语言 。 它 接受 由 一 种 AT&T 链接 器 控制 语法 的 超 集 编写 的 
链接 器 控制 语言 文件 ， 以 提供 对 链接 过 程 明 确 且 完全 的 控制 。 接 下 来 让 我 们 关注 其 中 细节 。 


我 们 可 以 通过 链接 器 语言 控制 : 


e 输入 文件 ; 
输出 文件 ; 
文件 格式 ; 
o 段 的 地 址 ; 
o 其 他 更 多 ... 


用 链接 器 控制 语言 编写 的 命令 通常 被 放 在 一 个 被 称 作 链接 器 脚本 的 文件 中 。 我 们 可 以 通过 命 
令 行 选项 -T 将 其 传递 给 1d 。 一 个 链接 器 脚本 的 主要 命令 是 SECTIONS 指令 。 每 个 链接 器 
脚本 必须 包含 这 个 指令 ， 并 且 其 决定 了 输出 文件 的 映射 。 特 丈 变量 .包含 了 当前 输出 的 位 
置 。 让 我 们 写 一 个 简单 的 汇编 程序 ， 然 后 看 看 如 何 使 用 链接 器 脚本 来 控制 程序 的 链接 。 我 们 
将 会 使 用 一 个 hello world 程序 作为 样 例 。 


.data 
msg .ascii "hello, world!", \n. 
.text 
global _start 
_start: 
mov $1, %rax 
mov $1,%rdi 
mov $msg, %rsi 
mov $14, %rdx 
syscall 
mov $60, %rax 
mov $0, %rdi 
syscall 


我 们 可 以 用 以 下 命令 编译 并 链接 : 


$ as -0 hello.o hello.asm 
$ ld -o hello hello.o 


我 们 的 程序 包含 了 两 个 段 : tet 包含 了 程序 的 代码 ， data 段 包 含 了 被 初始 化 的 变量 。 
让 我 们 写 一 个 简单 的 链接 脚本 ， 然 后 尝试 用 它 来 链接 我 们 的 hello.asm 汇编 文件 。 我 们 的 脚 
本 是 : 


/* 
* Linker script for the factorial 
Wh 

OUTPUT (hello) 

OUTPUT_FORMAT("elf64-x86-64") 

INPUT(hello.o) 


SECTIONS 
{ 
. = 0x200000; 
text 
*(.text) 
} 
. = 0x400000; 
,data : { 
*(.data) 
} 
} 


在 前 三 行 你 可 以 看 到 c 风格 的 注释 。 之 后 是 OUTPUT 和 ouTPUT_FoRMAT 命令 ， 指 定 了 我 们 
的 可 执行 文件 名 称 和 格式 。 下 一 个 指令 ，INPUT ， 指 定 了 给 1d 的 输入 文件 。 接 下 来 ， 我 们 
可 以 看 到 主要 的 sections 指令 ， 正 如 我 写 的 ， 它 是 必须 存在 于 每 个 链接 器 脚本 

P o sections 命令 表示 了 输出 文件 中 的 段 的 集合 和 顺序 。 在 SECTIONS 命令 的 开头 ， 我 们 可 
以 看 到 一 行 . = ox200000 。 我 上 面 已 经 写 过 ， |. 命令 指向 输出 中 的 当前 位 置 。 这 一 行 说 明 
代码 段 应 该 被 加 载 到 地 址 0x200000 © . = Ox400000 一 行 说 明 数据 段 应 该 被 加 载 到 地 

址 0x400000 ° . = ox200000 之 后 的 第 二 行 定 义 .text 作为 输出 段 。 我 们 可 以 看 到 其 中 的 * 
(.text) 表达 式 。 * 符号 是 一 个 匹配 任意 文件 名 的 通配符 。 换 名 话说 ，*(.text) 表达 式 代 
表 所 有 输入 文件 中 的 所 有 tet 输入 段 。 在 我 们 的 样 例 中 ， 我 们 可 以 将 其 重 写 为 
hello.o(.text) 。 在 地 址 计数 器 . = ox400000 之 后 ， 我 们 可 以 看 到 数据 段 的 定义 。 


我 们 可 以 用 以 下 语句 进行 编译 和 链接 : 


$ as -o hello.o hello.S && ld -T linker.script && ./hello 
hello, world! 


如 果 我 们 用 objdump 工具 深入 查看 ， 我 们 可 以 看 到 .text 段 从 地 址 ox200000 开始 ， 


.data FA 6x400000 开始 : 


$ objdump -D hello 
Disassembly of section .text: 


0000000000200000 <_start>: 
200000: 48 c7 cO 01 00 00 00 mov $0x1, %rax 


Disassembly of section .data: 


0000000000400000 <msg>: 
400000: 68 65 6c 6c 6f pushq $0x6f6c6c65 


除了 我 们 已 经 看 到 的 命令 ， 另 外 还 有 一 些 。 首 先是 ASSERT(exp, message) ， 保 证 给 定 的 表达 
式 不 为 震 。 如 果 为 震 ， 那 么 链接 器 会 退出 同时 返回 错误 码 ， 打 印 错误 信息 。 如 果 你 已 经 阅读 
了 linux-insides 的 Linux 内 核 启 动 流程 ， 你 或 许 知道 Linux 内 核 的 设置 头 的 偏 移 为 gxif1 ° 
在 Linux 内 核 的 链接 器 脚本 中 ， 我 们 可 以 看 到 下 面 的 校 验 : 


. = ASSERT(hdr == 0x1f1， "The setup header has the wrong offset!"); 


INCLUDE filename 允许 我 们 在 当前 的 链接 器 脚本 中 包含 外 部 符号 。 我 们 可 以 在 一 个 链接 器 脚 
本 中 给 一 个 符号 赋值 。 1d 支持 一 些 赋值 操作 符 : 


e symbol = expression ; 

e symbol += expression ; 
e symbol -= expression ; 
e symbol *= expression ; 
e symbol /= expression ; 

e symbol <<= expression ; 
e symbol >>= expression ; 
e symbol &= expression ; 
e symbol |= expression ; 


正如 你 注意 到 的 ， 所 有 操作 符 都 是 C 赋值 操作 符 。 比 如 我 们 可 以 在 我 们 的 链接 器 脚本 中 使 
用 : 


START_ADDRESS = 0x200000; 
DATA_OFFSET = 0x200000; 


SECTIONS 
{ 
. = START_ADDRESS; 
SECXE 3 4 
*(. text) 


. = START_ADDRESS + DATA_OFFSET; 
.data : { 
*(.data) 


如 


你 可 能 已 经 注意 到 了 链接 器 脚本 中 表达 式 的 语法 和 C 表达 式 相 同 。 除 此 之 外 ， 
BSR PAR BR: 


e ABSOLUTE - 返回 给 定 表达 式 的 绝对 值 ; 
© ADDR -接受 段 ， 返 回 其 地 址 ; 


这 个 链接 控制 


© ALIGN - 返回 和 给 定 表达 式 下 一 名 的 边界 对 齐 的 位 置 计数 器 ( ， 操作 符 ) 的 值 ; 


e DEFINED | ， 返回 1 ， 否 则 0 ; 
e MAX and MIN -返回 两 个 给 定 表 达 式 中 的 最 大 、 最 小 值 ; 

e NEXT -返回 一 个 是 当前 表达 式 倍 数 的 未 分 配 地 址 ; 

© SIZEOF -返回 给 定名 字 的 段 以 字 节 计数 的 大 小 。 


以 上 就 是 全 部 了 ° 


总 结 
这 是 关于 链接 器 文章 的 结尾 。 在 这 篇 文章 中 ， 我 们 已 经 学 习 了 很 多 关于 链接 器 
什么 是 是 链接 器 、 为 什么 a 、 如 何 使 用 它 等 等 ... 


如 果 你 发 现 文中 描述 有 任何 问题 ， 请 提交 一 个 PR 到 linux-insides-zh 。 


相关 链接 


e Book about Linux kernel insides 
e linker 

e object files 

e glibc 

e opcode 


的 知识 ， 比 如 


链接 器 
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e GNU linker 
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用 户 空 间 的 程序 启动 过 程 
简介 


虽然 linux-insides-zh 大 多 描述 的 是 内 核 相关 的 东西 ， 但 是 我 已 经 决定 写 一 个 大 多 与 用 户 空间 
相关 的 部 分 。 


系统 调用 章节 的 第 四 部 分 已 经 描述 了 当 我 们 想 运 行 一 个 程序 Linux 内 核 的 行为 。 这 部 分 我 
想 研 究 一 下 从 用 户 空间 的 角度 ， 当 我 们 在 Linux 系统 上 运行 一 个 程序 ， 会 发 生 什 么 。 


我 不 知道 你 知识 储备 如 何 ， 但 是 在 我 的 大 学 时 期 我 学 到 ， 一 个 c 程序 从 一 个 叫做 main YB 
数 开 始 执行 。 而 有 全， 这 是 部 分 正确 的 。 每 时 每 刻 ， 当 我 们 开始 写 一 个 新 的 程序 时 ， 我 们 从 下 
面 的 实例 代码 开始 编程 : 


int main(int argc, char *argv[]) { 
// Entry point is here 


} 


但 是 你 如 何 对 于 底层 编程 感 兴趣 的 话 ， 可 能 你 已 经 知道 main 郊 数 并 不 是 程序 的 丨 正 入 口 。 
如 果 你 在 调试 器 中 看 了 下 面 这 个 简单 程序 ， 就 可 以 很 确信 这 一 点 : 


int main(int argc, char *argv[]) { 
return 0; 


} 
让 我 们 来 编译 并 且 在 gdb 中 和 运行 这 个 程序 : 


$ gcc -ggdb program.c -0 program 

$ gdb ./program 

The target architecture is assumed to be 1386:x86-64:intel 
Reading symbols from ./program...done. 


这 个 指令 会 打印 关于 被 不 同 段 占据 的 内 存 和 调 


> 
i 


让 我 们 在 gdb 中 执行 info files 这 个 指 人 
试 目 标的 信息 。 


(gdb) info files 
Symbols from "/home/alex/program". 


Local exec file: 


注意 Entry point: 0x400430 这 一 行 。 现 在 我 们 知道 我 们 程序 入 口 点 的 站 正 地 址 。 让 我 们 在 这 


*/home/alex/program', file type elf64-x86-64. 


Entry point: 0x400430 


0x0000000000400238 - Ox0000000000400254 is .interp 
0x0000000000400254 - 0x0000000000400274 is .note.ABI-tag 
0x0000000000400274 - Ox0000000000400298 is .note.gnu.build-id 
©x0000000000400298 - Ox00000000004002b4 is .gnu.hash 
0x00000000004002b8 - 0x0000000000400318 is .dynsym 
0x0000000000400318 - Ox0000000000400357 is .dynstr 
©x0000000000400358 - Ox0000000000400360 is .gnu.version 
0x0000000000400360 - 0x0000000000400380 is .gnu.version_r 
0x0000000000400380 - 0x0000000000400398 is .rela.dyn 
0x0000000000400398 - Ox00000000004003c8 is .rela.plt 
Ox00000000004003c8 - Ox00000000004003e2 is .init 
Ox00000000004003FO - Ox0000000000400420 is .plt 
0x0000000000400420 - 0x0000000000400428 is .plt.got 
0x0000000000400430 - Ox00000000004005e2 is .text 
0x00000000004005e4 - 0x00000000004005ed is .fini 
Ox00000000004005FO - Ox0000000000400610 is .rodata 
0x0000000000400610 - Ox0000000000400644 is .eh_frame_hdr 
0x0000000000400648 - 0x000000000040073c is .eh_frame 
0x0000000000600e10 - Ox0000000000600e18 is .init_array 
0x0000000000600e18 - Ox0000000000600e20 is .fini_array 
0x0000000000600e20 - Ox0000000000600e28 is .jcr 
0x0000000000600e28 - 0x0000000000600ff8 is .dynamic 
0x0000000000600ff8 - Ox0000000000601000 is .got 
0x0000000000601000 - 0x0000000000601028 is .got.plt 
Ox0000000000601028 - Ox0000000000601034 is .data 
0x0000000000601034 - 0x0000000000601038 is .bss 


个 地 址 下 一 个 断 点 ， 然 后 运行 我 们 的 程序 ， 看 看 会 发 生 什么 : 


(gdb) break *0x400430 


Breakpoint 1 at 0x400430 


(gdb) run 
Starting program: /home/alex/program 


Breakpoint 1, 0x0000000000400430 in _start () 


有 趣 。 我 们 并 没有 看 见 main 函数 的 执行 ， 但 是 我 们 看 见 另 外 一 个 函数 被 调用 。 这 个 函数 是 
_start 而 且 根 据 调 试 器 展现 给 我 们 看 的 ， 它 是 我 们 程序 的 真正 入 口 。 那 么 ， 这 个 函数 是 从 哪 
里 来 的 ， 又 是 谁 调用 了 这 个 main 函数 ， 什 么 时 候 调 用 的 。 我 会 在 后 续 部 分 尝试 回答 这 些 问 
题 。 


内 核 如 何 运 行 新 程序 
首先 ， 让 我 们 来 看 一 下 下 面 这 个 简单 的 Cc 程序 : 


// program.c 


#include <stdlib.h> 
#include <stdio.h> 


static Ine x = I; 
int y = 2; 


int main(int argc, char *argv[]) { 
int z = 3; 


Brunet (oe ae Whar v4 = oN oe ae SY tz 


return EXIT_SUCCESS; 


我 们 可 以 确定 这 个 程序 按照 我 们 预期 那样 工作 。 让 我 们 来 编译 它 : 


$ gcc -Wall program.c -0 sum 


并 且 执 行 
$ ./sum 


x+yt+Z2=6 


好 的 ， 直 到 现在 所 有 事情 看 起 来 听 插 好。 你 可 能 已 经 知道 一 个 特殊 的 系统 调用 家 族 - exec* A 
统 调用 。 正 如 我 们 从 帮助 手册 中 读 到 的 : 
The exec() family of functions replaces the current process image with a new process 
image. 


如 果 你 已 经 阅读 过 系统 调用 章节 的 第 四 部 分 ， 你 可 能 就 知道 execve 这 个 系统 调用 定义 在 
files/exec.c 文件 中 ， 并 且 如 下 所 示 ， 


SYSCALL_DEFINE3(execve, 
const char __user *, filename, 


* 


const char __user *const __user *, argv, 
const char __user *const __user *, envp) 


return do_execve(getname(filename), argv, envp); 


它 以 可 执行 文件 的 名 字 ， 命 令 行 参 数 的 集合 以 及 环境 变量 的 集合 作为 参数 。 正 如 你 猜测 的 ， 

每 一 件 事 都 是 do_execve 函数 完成 的 。 在 这 里 我 将 不 描述 这 个 函数 的 实现 细节 ， 因 为 你 可 以 

从 这 里 读 到 。 但 是 ， 简 而 言 之 ， do_execve 函数 会 检查 诸如 文件 名 是 否 有 效 ， 未 超出 进程 数 

目 限 制 等 等 。 些 检查 之 后 ， 这 个 函数 会 解析 ELF 格式 的 可 执行 文件 ， 为 新 的 可 执行 文件 
创建 内 存 描述 符 ， 并 且 在 栈 ， 站 和 内 大根 上 汉人 。 当 二 进 制 镜像 设置 完 

成 ，start_thread 函数 会 设置 一 个 新 的 进程 。 这 个 函数 是 框架 相关 的 ， 而 且 对 于 x86 64 框 

架 ， 它 的 定义 是 在 arch/x86/kernel/process 64.c 文件 中 。 


start_thread 为 段 寄 存 器 设置 新 的 值 。 从 这 一 点 开始 ， 新 进程 已 经 准备 就 绪 。 一 旦 进程 切换 ) 
完成 ， 控 制 权 就 会 返回 到 用 户 空 间 ， 并 且 新 的 可 执行 文件 将 会 执行 。 


这 就 是 所 有 内 核 方面 的 内 容 。Linux 内 核 为 执行 准备 二 进 制 镜像 ， 而 且 它 的 执行 从 上 下 文 切 换 
开始 ， Pe = 间 。 但 是 它 并 不 能 回答 像 start 来 自 哪里 这 样 的 问 
题 。 让 我 们 在 下 一 段 尝试 回答 这 些 问题 。 


AP lal Pte ty eB 


在 之 前 的 段落 汇总 ， 我 们 看 到 了 内 核 是 如 何 为 可 执行 文件 运行 做 准备 工作 的 。 让 我 们 从 用 户 

空间 来 看 这 相同 的 工作 。 我 们 已 经 知道 一 个 程序 的 入 口 点 是 start 函数 。 但 是 这 个 函数 是 
从 哪里 来 的 呢 ? 它 可 能 来 自 于 一 个 库 。 但 是 如 果 你 记得 清楚 的 话 ， 我 们 在 程序 编译 过 程 中 并 
没有 链接 任何 库 。 


$ gcc -Wall program.c -0 sum 
你 可 能 会 猜 start 来 自 于 标准 库 。 是 的 ， 确 实 是 这 样 。 如 果 你 尝试 去 重新 编译 我 们 的 程 


这 
序 ， 并 给 gcc a verbose mode 的 -v 选项 ， 你 会 看 到 下 面 的 长 输出 。 我 们 并 不 
对 整体 输出 感 兴趣 ， 让 我 们 来 看 一 下 下 面 的 步骤 : 


首先 ， 使 用 gcc 编译 我 们 的 程序 : 


$ gcc -v -ggdb program.c -0 sum 


/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/cc1 -quiet -v program.c -quiet -dumpbase pr 
ogram.c -mtune=generic -march=x86-64 -auxbase test -ggdb -version -o /tmp/ccvUWZkF.s 


col 编译 器 将 编译 我 们 的 c 代码 并 且 生 成 /tmp/ccvuwzkF.s 汇编 文件 。 之 后 我 们 可 以 看 见 
我 们 的 汇编 文件 被 GNU as 编译 器 编译 为 目标 文件 : 


$ gcc -v -ggdb program.c -0 Sum 


as -v --64 -o /tmp/cc79wZSU.o /tmp/ccvUWZkF.s 


最 后 我 们 的 目标 文件 会 被 collect2 链接 到 一 起 : 


$ gcc -v -ggdb program.c -0 sum 


/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/collect2 -plugin /usr/libexec/gcc/x86_64-re 
dhat-linux/6.1.1/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/6.1 
.1/lto-wrapper -plugin-opt=-fresolution=/tmp/ccLEGYra.res -plugin-opt=-pass-through=-1 
gcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass- 
through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --no-add-needed --eh-frame- 
hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /1ib64/l1d-linux-x86-64.so.2 -o test 
/usr/lib/gcc/x86_64-redhat -linux/6.1.1/../../../../1ib64/crt1.0 /usr/lib/gcc/x86_64-r 
edhat-linux/6.1.1/../../../../1i1b64/crti.o /usr/lib/gcc/x86_64-redhat-linux/6.1.1/crtb 
egin.o -L/usr/lib/gcc/x86_64-redhat-linux/6.1.1 -L/usr/lib/gcc/x86_64-redhat-linux/6.1 
.1/../../../../lib64 -L/lib/../1ib64 -L/usr/lib/../1ib64 -L. -L/usr/lib/gcc/x86_64-red 
hat-linux/6.1.1/../../7.. /tmp/cc79wZSU.o -lgcc --as-needed -lgcc_s --no-as-needed -1c 

-lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/6.1.1/crtend 
,0 /usr/lib/gcc/x86_64-redhat-linux/6.1.1/../../../../1ib64/crtn.o 


是 的 ， 我 们 可 以 看 见 一 个 很 长 的 命令 行 选 项 列表 被 传递 给 链接 器 。 让 我 们 从 另 一 条 路 行进 。 
我 们 知道 我 们 的 程序 都 依赖 标准 库 。 


$ ldd program 
linux-vdso.so.1 (0x00007ffc9afd2000 ) 
libc.so.6 => /1ib64/libc.so.6 (0x00007f56b389b000 ) 
/1ib64/1d-1linux-x86-64.s0.2 (0x0000556198231000) 


从 那里 我 们 会 用 一 些 库 函 数 ， 像 printf 。 但 是 不 止 如 此 。 这 就 是 为 什么 当 我 们 给 编译 器 传 
递 -nostdlib 参数 ， 我 们 会 收 到 错误 报告 : 


$ gcc -nostdlib program.c -o program 

/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 000000000040017c 
/tmp/ccO2msGW.o: In function ‘main': 

/home/alex/program.c:11: undefined reference to ‘printf' 

collect2: error: ld returned 1 exit status 


除了 这 些 错误 ， 我 们 还 看 见 start 符号 未 定义 。 所 以 现在 我 们 可 以 确定 start 函数 来 自 
于 标准 库 。 但 是 即使 我 们 链接 标准 库 ， 它 也 无 法 成 功 编译 : 


$ gcc -nostdlib -lc -ggdb program.c -o program 
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000400350 


好 的 ， 当 我 们 使 用 /usr/1ib64/1ibc.so.6 链接 我 们 的 程序 ， 编 译 器 并 不 报告 标准 库 函 数 的 未 
定义 引用 ， 但 是 start 符号 仍然 未 被 解析 。 让 我 们 重新 回 到 goo 的 完 长 输出 ， 看 看 
collect2 的 参数 。 我 们 现在 最 重要 的 问题 是 我 们 的 程序 不 仅 链接 了 标准 库 ， 还 有 一 些 目标 广 
件 。 第 一 个 目标 文件 是 /Lib64/crt1.o 。 而 且 ， 如 果 我 们 使 用 objdump 工具 去 看 这 个 目标 文 
件 的 内 部 ， 我 们 将 看 见 _start 符号 : 


$ objdump -d /1ib64/crt1.o 


/1ib64/crti.o: file format elf64-x86-64 


Disassembly of section .text: 


0000000000000000 <_start>: 


0: 31 ed xor %ebp, %ebp 

2 49 89 d1 mov %rdx,%r9 

5 5e pop %rsi 

6: 48 89 e2 mov %rsp,%rdx 

9: 48 83 e4 fO and $Oxfffffffffffffff0,%rsp 
d 50 push %rax 

e 54 push %rsp 

f 49 c7 cO 00 00 00 00 mov $0x0, %r8 

16: 48 c7 c1 00 00 00 00 mov $0x0, %rcx 

dd: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 

24: e8 00 00 00 00 callq 29 <_start+0x29> 
29: f4 hlt 


AA crti.o -ARFER ’ HURN RANE NTE EEN ARAR o ERRE 
一 下 _start 远 数 的 源码 。 因 为 这 个 函数 是 框架 相关 的 ， 所 以 start 的 实现 是 在 
sysdeps/x86_64/start.S 这 个 汇编 文件 中 。 


_start 始 于 对 ebp 寄存 器 的 清 零 ， 正 如 ABI) 所 建议 的 。 


xorl %ebp, %ebp 


Ze? HA HRN RIS) rg 寄存 器 中 : 


mov %RDX_LP, %R9_LP 


正如 ELF 标准 所 述 ， 


After the dynamic linker has built the process image and performed the relocations, 
each shared object gets the opportunity to execute some initialization code. ... Similarly, 
shared objects may have termination functions, which are executed with the atexit 
(BA_OS) mechanism after the base process begins its termination sequence. 


所 以 我 们 需要 把 终止 函数 的 地 址 放 到 ro 寄存 器 ， 因 为 将 来 它 会 被 当 作 第 六 个 参数 传递 给 
_libc_start_main ° 注意 ， 终 止 函 数 的 地 址 初始 是 存储 在 rdx 寄存 器 。 除 了 %rdx 和 
%rsp 之 外 的 其 他 寄存 器 保存 未 确定 的 值 。 _start BAP ALE Be A 
_libc_start_main 。 所 以 下 一 步 就 是 为 调用 这 个 函数 做 准备 。 


libc_start_main 的 实现 是 在 csullibc-start.c 文件 中 。 让 我 们 来 看 一 下 这 个 函数 : 


STATIC int LIBC_START_MAIN (int (*main) (int, char **, char **), 
int argc, 
char **argv, 
__typeof (main) init, 
void (*fini) (void), 
void (*rtld_fini) (void), 
void *stack_end) 


It takes address of the main function of a program, argc and argv. init and fini 
functions are constructor and destructor of the program. The rtid_fini is termination 
function which will be called after the program will be exited to terminate and free dynamic 
section. The last parameter of the _ libc_ start main is the pointer to the stack of the 
program. Before we can call the _ lipc start_ main function, all of these parameters must 
be prepared and passed to it. Let's return to the sysdeps/x86_64/start.S assembly file and 
continue to see what happens before the _ libc_start_main function will be called from 
there. 


该 函数 以 程序 main 有 函数 的 地 址 ， argc 和 argv 作为 输入 °> init 和 fini 函数 分 别 是 程 
序 的 构造 函数 和 析 构 函数 。 rtld_fini 是 当 程 序 退 出 时 调用 的 终止 函数 ， 用 来 终止 以 及 释放 
动态 段 。 _libc_start_main 函数 的 最 后 一 个 参数 是 一 个 指向 程序 栈 的 指针 。 在 我 们 调用 
_libe_start_main 坎 数 之 前 ， 所 有 的 参数 都 要 被 准备 好 ， 并 且 传 递 给 它 。 让 我 们 返回 
sysdeps/x86 64/start.S 这 个 文件 ， 继 续 看 在 _1libc_start_main 被 调用 之 前 发 生 了 什么 。 


我 们 可 以 从 栈 上 获取 我 们 所 需 的 _libc_start main 的 所 有 参数 。 当 start 被 调用 的 时 
候 ， 我 们 的 栈 如 下 所 示 : 


站 十 
| NULL | 
人 十 
| envp | 
站 十 
| NULL | 
She Oe eae ae 
| argv | <- rsp 
fo ye ee E E 
| argc | 
本 下 十 


BS? HAAG AE BAILS ro 寄存 器 中 之 后 ， 我 们 取出 栈 


当 我 们 清 零 了 ebp F 
寄存 器 中 。 最 终 rsp 指向 argv 数组 ， rsi 保存 传递 给 程序 的 命令 行 


顶 元 素 ， 放 到 rsi 
参数 的 数目 : 


| NULL | 
让 十 
| envp | 
se + 
| NULL | 
E EN E AE NES N 
| argv | <- rsp 
站 十 


这 之 后 ， 我 们 将 argv 数组 的 地 址 赋值 给 rdx 寄存 器 中 。 


popq %rsi 
mov %RSP_LP, %RDX_LP 


从 这 一 时 刻 开 始 ， 我 们 已 经 有 了 arge 和 argv 。 我 们 仍 要 将 构造 函数 和 析 构 函数 的 指针 放 


到 合适 的 寄存 器 ， 以 及 传递 指向 栈 的 指针 。 下 面 汇编 代码 的 前 三 行 按 照 ABI| 中 的 建议 设置 栈 


为 16 字 节 对 齐 ， 并 将 ras BR: 


and $~15, %RSP_LP 
pushq %rax 


pushq %rsp 

mov $__libc_csu_fini, %R8_LP 
mov $__libc_csu_init, %RCX_LP 
mov $main, %RDI_LP 


栈 对 齐 之 后 ， 我 们 压 栈 栈 的 地 址 ， 并 且 将 构造 函数 和 析 构 函数 的 地 址 放 到 r8 和 rcx 寄存 


器 中 ， 同 时 将 main 函数 的 地 址 放 到 rdi 寄存 器 中 。 从 这 个 时 刻 开 始 ， 我 们 可 以 调用 
csu/libc-start.c 中 的 _1ibc start main Hak ° 


在 我 们 查看 _1libc_start_main 函数 之 前 ， 让 我 们 添加 /lib64/crt1.o 文件 并 且 再 次 尝试 编 


译 我 们 的 程序 : 


$ gcc -nostdlib /1ib64/crti.o -lc -ggdb program.c -o program 
/1ib64/crt1.0: In function ~_start': 


(.text+0x12): undefined reference to ~__libc_csu_fini' 
/1ib64/crt1.0: In function ~_start': 
(.text+0x19): undefined reference to ~__libc_csu_init' 


collect2: error: ld returned 1 exit status 


现在 我 们 看 见 了 另外 一 个 错误 -未 找到 ”1ibc csu fini 和 ”1ibc csu init 。 我 们 知道 这 
两 个 函数 的 地 址 被 传递 给 ”1ibc_start_main 作为 参数 ， 同 时 这 两 个 函数 还 是 我 们 程序 的 构 


造 函 数 和 析 构 函数 。 但 是 在 5 程序 中 ， 构 造 函 数 和 析 构 函数 意味 着 什么 呢 ?我们 已 经 在 


ELF 标准 中 看 到 : 


After the dynamic linker has built the process image and performed the relocations, 
each shared object gets the opportunity to execute some initialization code. ... Similarly, 
shared objects may have termination functions, which are executed with the atexit 
(BA_OS) mechanism after the base process begins its termination sequence. 


所 以 链接 器 除了 一 般 的 段 ， 如 .text , data 之 外 创建 了 两 个 特殊 的 段 : 


© .init 


e fini 
We can find it with reade1f util: 


我 们 可 以 通过 readelf 工具 找到 它们 : 


$ readelf -e test | grep init 
[11] .init PROGBITS 00000000004003c8 000003c8 


$ readelf -e test | grep fini 
[15] .fini PROGBITS 0000000000400504 00000504 


TEA AE BARRA AIA BEAR OY EM fe LSD BBA A A E Fe HH BIO BIA o 
REGAN AA es eral taint a te 些 初 始 化 /终结 ， 像 全 局 变量 如 errno ， 
为 系统 例 程 分 配 和 释放 内 存 等 等 。 


你 可 能 可 以 从 这 些 函 数 的 名 字 推 测 ， 这 两 个 会 在 main 函数 之 前 和 之 后 被 调用 。 .init 和 
fini 段 的 定义 在 /1ib64/crti.o 中 。 如 果 我 们 添加 这 个 目标 文件 : 


$ gcc -nostdlib /1ib64/crt1.0 /1ib64/crti.o -lc -ggdb program.c -o program 


我 们 不 会 收 到 任何 错误 报告 。 但 是 让 我 们 尝试 去 运行 我 们 的 程序 ， 看 看 发 生 什么 


$ ./program 
Segmentation fault (core dumped) 


是 的 ， 我 们 收 到 segmentation fault 。 让 我 们 通过 objdump AA 1ib64/crti.o NAR: 


$ objdump -D /1ib64/crti. 


o 


/lib64/crti.o: file format elf64-x86-64 


Disassembly of section .i 


0000000000000000 <_init>: 


0: 48 83 ec 08 

4: 48 8b 05 00 00 0 
b: 48 85 c0 

el 74 05 

10: e8 00 00 00 00 


Disassembly of section .f 


0000000000000000 <_fini>: 
0: 48 83 ec 08 


正如 上 面 所 写 的 ， /1ib64/crti.o 


nit: 


sub 

0 00 mov 
test 
je 
callq 


ini: 


sub 


$0x8,%rsp 

Ox0(%rip),%rax # b <_init+0xb> 
%rax,%rax 

15 <_init+0x15> 

15 <_init+0x15> 


$0x8,%rsp 


目标 文件 包含 init 和 fini 段 的 定义 ， 但 是 我 们 可 


看 见 这 个 函数 的 桩 。 让 我 们 看 一 下 sysdeps/x86 64/crti.S 文件 中 的 源码 : 


,Section .init,"ax",@progbits 


.p2align 2 

.globl _init 

.type _init, @functio 
_init: 

subq $8, %rsp 


n 


movq PREINIT_FUNCTION@GOTPCREL(%rip), %rax 


testq %rax, %rax 
je .Lno_weak_fn 
call *%rax 
. Lno_weak_fn: 
call PREINIT_FUNCTION 


~ 


X 


包含 .init 段 的 定义 ， 而 且 汇 编 代 码 设 置 16 字 节 的 对 齐 。 之 后 ， 如 果 它 不 是 零 ， 我 们 调 


它 
用 PREINIT_FUNCTION ; 否则 


00000000004003c8 <_init>: 


4003c8: 48 83 ec 
4003cc: 48 8b 05 
YNAMIC+0x1d0> 

4003d3: 48 85 cO 
4003d6: 74 05 
4003d8: e8 43 00 
4003dd: 48 83 c4 
4003e1: c3 


不 调用 : 


08 
25 Oc 20 00 


00 00 
08 


sub $0x8,%rsp 
mov 0x200c25(%rip), %rax # 600ff8 < D 


test %rax, %rax 

je 4003dd <_init+0x15> 

callq 400420 <_libc_start_main@p1t+0x10> 
add $0x8,%rsp 

retq 


where the PREINIT_FUNCTION is the _ gmon start which does setup for profiling. You may 
note that we have no return instruction in the sysdeps/x86_64/crti.S. Actually that's why we 
got segmentation fault. Prolog of _init and _fini is placed in the sysdeps/x86_64/crtn.S 
assembly file: 





其 中 ， pREINIT_FUNCTION 是 设置 简况 的 gmon start 。 你 可 能 发 现 ， 在 
sysdeps/x86 64/crti.S 中 ， 我 们 没有 return 指令 。 事 实 上 ， 这 就 是 我 们 获得 segmentation 
fault 的 原因 。 _init 和 _fini 的 序言 被 放 在 sysdeps/x86 64/crtn.S 汇编 文件 中 : 





,Section .init,"ax",@progbits 
addq $8, %rsp 
ret 


.section .fini,"ax",@progbits 


addq $8, %rsp 
ret 


如 果 我 们 把 它 加 到 编译 过 程 中 ， 我 们 的 程序 会 被 成 功 编译 和 和 运行。 


$ gcc -nostdlib /1ib64/crti.o /1ib64/crti.o /1ib64/crtn.o -lc -ggdb program.c -o prog 
ram 


$ ./program 
x+y+z=6 


结论 


现在 让 我 们 回 到 start 函数 ， 以 及 尝试 去 浏览 main 函数 被 调用 之 前 的 完整 调用 链 。 


_start 总 是 被 默认 的 1d 脚本 链接 到 程序 text 段 的 起 始 位 置 : 


$ ld --verbose | grep ENTRY 
ENTRY(_start) 


_start BAT LH sysdeps/x86 64/start.S 汇编 文件 中 ， 并 且 在 _libc_start_main 被 调用 
之 前 做 一 些 准备 工作 ， 像 从 栈 上 获取 argc/argv ， 栈 准备 等 。 来 自 于 csullibc-start.c 文件 中 
的 _1ibc_start_main 哆 数 注册 构造 函数 和 析 构 函数 ， 开 启 线程 ， 做 一 些 安全 相关 的 操作 ， 
比如 在 有 需要 的 情况 下 设置 stack canary ， 调 用 初始 化 ， 最 后 调用 程序 的 main 函数 以 及 返 
回 结果 退出 。 而 构造 函数 和 析 构 函数 分 别 是 main 之 前 和 之 后 被 调用 。 


result = main (argc, argv, _ environ MAIN_AUXVEC_PARAM) ; 
exit (result); 


用 户 空 间 的 程序 启动 过 程 
结束 


链接 


e system call 

e gdb 

e execve 

e ELF 

e x86 64 

e segment registers 
e context switch 

e System V ABI 


777 


Linux 内 核 内 部 系统 数据 结构 


这 不 是 linux-insides-zh 中 的 一 般 章节 。 正 如 你 从 题目 中 理解 到 的 ， 它 主要 描述 Linux 内 核 
中 的 内 部 系统 数据 结构 。 比 如 说 ， 中 断 描述 符 表 ( Interrupt Descriptor Table )， 全 局 描述 符 
表 ( Global Descriptor Table ) ° 


大 部 分 信息 来 自 于 Intel 和 AMD 官方 手册 。 


中 断 描 述 符 (IDT) 


三 个 常见 的 中 断 和 异常 来 源 : 


。 故障 - 在 指令 导致 异常 之 前 会 被 准确 地 报告 。 wrip 保存 的 指针 指向 故障 的 指令 ; 
。 陷阱 - 在 指令 导致 异常 之 后 会 被 准确 地 报告 。 wrip 保存 的 指针 同样 指向 故障 的 指令 ; 
。 终止 - 是 不 明确 的 异常 。 因 为 它们 不 能 被 明确 ， 中 止 通常 不 允许 程序 可 靠 地 再 次 启动 。 


只 有 当 RFLAGS.IF = 1 时 ， 可 屏蔽 中 断 触 发 才 中 断 处 理 程序 。 除非 RFLAGS.IF 位 清 零 ， 否 则 
它们 将 持续 处 于 等 待 处 理 状态 。 


不 可 屏蔽 PH (NMI) 不 受 rFLAGS.IF 位 的 影响 。 无 论 怎 样 一 个 NMI 的 发 生 都 会 进一步 屏蔽 之 
后 的 其 他 NMI， 直 到 执行 IRET (中 断 返 回 ) 指令 。 


具体 的 异常 和 中 断 来 源 被 分 配 了 固定 的 向 量 标识 号 (也 称 " 中 断 向 量 ?" 或 简称 “向 量 ") 。 中 断 处 
理 程序 使 用 中 断 向 量 来 定位 异常 或 中 断 ， 从 而 分 配 相应 的 系统 软件 服务 处 理 程序 。 有 至 多 256 
个 特殊 的 中 断 向 量 可 用 。 前 32 个 是 保留 的 ， 用 于 预定 义 的 异常 和 中 断 条 件 。 请 参考 arch / x86 
/include /asm /traps.h 头 文件 中 对 他 们 的 定义 : 


/* 中 断 / 异 常 */ 


enum { 
X86_TRAP_DE = 0, /* 0， 除 零 错误 */ 
X86_TRAP_DB, fA aXe */ 
X86_TRAP_NMI, /* 2， 不 可 屏蔽 中 断 */ 
X86_TRAP_BP, /* 3, OR */ 
X86_TRAP_OF, Hi E SY 
X86_TRAP_BR, /* 5, RH */ 
X86_TRAP_UD, /* 6， 操作 码 无 效 */ 
X86_TRAP_NM, Ey, BES TN 
X86_TRAP_DF, /* 8， 双 精度 浮 点 错误 */ 
X86_TRAP_OLD_MF, /* 9, WRB */ 
X86_TRAP_TS, /* 10, Æ% TSS */ 
X86_TRAP_NP, /* 11, RAGE */ 
X86_TRAP_SS, /* 12, HERP */ 
X86_TRAP_GP, /* 13， 一 般 保护 故障 */ 
X86_TRAP_PF, /* 14, WR */ 
X86_TRAP_SPURIOUS, /* 15, APR */ 
X86_TRAP_MF, /* 16, x87 浮 点 异常 */ 
X86_TRAP_AC, /* 17, HHIRE */ 
X86_TRAP_MC, /* 18, MER */ 
X86_TRAP_XF, /* 19, SIMD ( 单 指令 多 数据 结构 浮 点 ) 异常 */ 
X86_TRAP_IRET = 32, /* 32, IRET (PRA) 异常 */ 

J; 
吴 代 码 (Error code ) 

处 理 器 异常 处 理 程序 使 用 错误 代码 报告 某 些 异常 的 错误 和 状态 信息 。 在 控制 权 交 给 异常 处 理 


程序 期 间 ， 异 常 处 理 装 Go 到 堆栈 中 。 错 误 代 码 有 两 种 格式 : 


© 多 数 异 常 错误 报告 格式 ; 
页 错误 格式 。 


选择 子 错误 代码 的 格式 如 下 : 


31 16 15 3 2 ak 0 

站 十 

| | ITI IIE 

| Reserved | Selector Index |} - | D | X | 

| | VETA ETA T] 

es pesos So paue ane + 
说 明 如 下 : 


e EXT - 如 果 该 位 设置 为 1， 则 异常 源 在 处 理 器 外 部 。 如 果 设 置 为 0， 则 异常 源 位 于 处 理 器 
的 内 部 ; 
e IDT - 如 果 该 位 设置 为 1， 则 错误 代码 选择 子 索引 字段 引用 位 于 “中 断 描述 符 表 "中 的 门 描 


述 符 。 如 果 设 置 为 0， 则 选择 子 索 引 字段 引用 "全 局 描述 符 表 ? 或 本 地 描述 符 表 “LDT? 中 的 
兽 述 符 ， 由 “TPP 位 所 指示 ; 

© TI -如 果 该 位 设置 为 1， 则 错误 代码 选择 子 索 引 字 段 引 用 “LDT” 中 的 描述 符 。 如 果 清 除 
为 0， 则 选择 子 索 引 字 段 引 用 “GDT" 中 的 描述 符 ; 

e Selector Index - 选择 子 索 引 字 段 指定 索引 为 “GDT'，"LDT" 或 "IDT”， 它 是 
由 “IDT" 和 "“Tl" 位 指定 的 。 


页 错误 代码 格式 如 下 : 


31 de vs 2 all 0 
(SAS dares Soos SSS Sessa sesSoSSSs ceed sas telson se sases sess ss Soeese ss essuscesesossase + 
| | [Ra UR 
| Reserved | I/D | S| -|-]|P | 
| | LAAS al Na 
RE + 
说 明 如 下 : 


© I/D - 如 果 该 位 设置 为 1， 表 示 造 成 页 错误 的 访问 是 取 指 ; 

e RSV - 如 果 该 位 设置 为 1， 则 页 错误 是 处 理 器 从 保留 给 分 页 表 的 区 域 中 读 取 1 的 结果 ; 

© us - 如 果 该 位 被 设置 为 0， 则 是 管理 员 模 式 ( cpL = 0,1 或 2 ) 进行 访问 导致 了 页 错误 。 
如 果 该 位 设置 为 1， 则 是 用 户 模式 (CPL = 3) 进行 访问 导致 了 页 错误 ; 

© RW - 如 果 该 位 被 设置 为 0， 导 致 页 错误 的 是 内 存 读 取 。 如 果 该 位 设置 为 1， 则 导致 页 错 
误 的 是 内 存 写 入 ; 

© p - 如 果 该 位 被 设置 为 0， 则 页 错误 是 由 不 存在 的 页 面 引 起 的 。 如果 该 位 设置 为 1， 页 错 
误 是 由 于 违反 页 保护 引起 的 。 


中 断 控制 传输 (Interrupt Control Transfers ) 


IDT 可 以 包含 三 种 门 描述 符 中 的 任何 一 种 : 


e task Gate (任务 门 ) - 包含 用 于 异常 与 或 中 断 处 理 程序 任务 的 TSS 的 段 选择 子 ; 

e Interrupt Gate (中 断 门 ) - 包含 处 理 器 用 于 将 程序 从 执行 转移 到 中 断 处 理 程序 的 段 选择 子 
和 偏 移 量 ; 

e Trap Gate (MIT) - 包含 处 理 器 用 于 将 程序 从 执行 转移 到 异常 处 理 程序 的 段 选 择 子 和 偏 


门 的 一 般 格式 是 : 


Op CORES eo a ae See GOOG Ses ae SS ORR eS See Sr P eee Se Shears Aone ana + 
| | 
| Reserved | 
| | 
二 
95 64 
Eo E + 


0 + 
63 48 47 46 44 42 39 34 32 
P + 
l l | | | | C d | 
| Offset 31..16 | P | P | © |Type [© 00 | © | © | IST | 
| | | L | | | a al | 
要 十 
31 16 15 0 
a a a a + 
l | | 
| Segment Selector | Offset 15..0 | 
| | | 
Pe + 


说 明 如 下 : 


e selector - 目标 代码 段 的 段 选 择 子 ; 

© offset -处 理 程序 入 口 点 的 偏 移 量 ; 

© DPL - 描述 符 权 限 级别 ; 

e p -当前 段 标 志 ; 

e IST -中断 堆栈 表 ; 

e type -本 地 描述 符 表 (LDT) 段 描述 符 ， 任 务 状态 段 (TSS) 描述 符 ， 调 用 门 描 述 符 ， 
中 断 门 描述 符 ， 陷 阱 门 描述 符 或 任务 门 描述 符 之 一 。 


IDT 描述 符 在 Linux 内 核 中 由 以 下 结构 表示 ( 仅 适 用 于 x86_64 ) 


struct gate_struct64 { 
U16 offset_low; 
u16 segment; 
unsigned St Zero00 B isi, EyYDe S dn B45 fo) Gale 
u16 offset_middle; 
u32 offset_high; 
u32 zeroi1; 
} __attribute__((packed)); 


它 定义 在 arch/x86/include/asm/desc_defs.h 头 文件 中 。 


任务 门 描述 符 不 包含 ist 字段 ， 并 且 其 格式 与 中 断 /陷阱 门 不 同 : 
struct ldttss_desc64 { 
u16 limit0; 
u16 based; 
unsigned basei : 8, type : 5, dpl : 2, p: 1; 
unsigned limit1 : 4, zero0 : 3, g : 1, base2 : 8; 
u32 base3; 


u32 Zerol 
} __attribute__((packed)); 


任务 切换 期 间 的 异常 《Exceptions During a Task 
Switch ) 


任务 切换 在 加 载 段 选择 子 期 间 可 能 会 发 生 异 常 。 页 错误 也 可 能 会 在 访问 TSS 时 出 现 。 在 这 些 
情况 下 ， 由 硬件 任务 切换 机 构 完成 从 TSS 加 载 新 的 任务 状态 ， 然 后 触发 适当 的 异常 处 理 。 


在 长 模式 下 ， 由 于 硬件 任务 切换 机 构 被 禁用 ， 因 而 在 任务 切换 期 间 不 会 发 生 蜡 常 。 


不 可 屏蔽 中 断 (Nonmaskable interrupt) 


API 


中 断 堆 栈 表 (Interrupt Stack Table ) 


有 帮助 的 链接 


Linux 局 动 


e Linux/x86 boot protocol 
e Linux kernel parameters 


保护 模式 


e 64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf 


串口 编程 


e 8250 UART Programming 
e Serial ports on OSDEV 


VGA 


e Video Graphics Array (VGA) 


IO 


e |O port programming 


GCC and GAS 


e GCC type attributes 
e Assembler Directives 


重要 的 数据 结构 


e task_struct definition 


有 帮助 的 链接 


其 他 框架 


e PowerPC and Linux Kernel Inside 


有 帮助 的 链接 


e Linux x86 Program Start Up 
e Memory Layout in Program Execution (32 bits) 
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